we need a spec for handling mediums
m.hearn at signal.QinetiQ.com
Thu Aug 26 11:20:41 EEST 2004
> I think that realistically, people will install newer versions of whatever
> they need in order to run the program they *really* want. They're already
> installing stuff (the program they really want), so installing a couple more
> things at the same time isn't so bad. Realistically, they already do it.
> Maybe they don't want to, but mostly they don't get a choice in the matter,
> because almost all the programs need some random version of some random
> library. Zero install is a partial solution to that. Debian's apt is
I agree this is OT but couldn't let this one slide ... my experience of
dealing with Linux newbies of whatever previous skill level is that they
either won't upgrade libraries at all (and just make do with old
software) OR they attempt to do so not really understanding what they're
getting themselves into and break their system horribly.
- upgrading GTK on a RH9/FC1 box will break GNOME.
- upgrading glibc (a very common one as due to symbol versioning RPM
usually tells you to upgrade libc when an RPM built for a newer distro
is used) is a great way to make your system unbootable. I've seen some
people install eg a SuSE glibc RPM on Red Hat and not understand why it
doesn't work: after all, why should they?
- upgrading the distro itself can fail in the presence of things like
- having to upgrade your distro the moment it comes out in order to
follow the packagers is a real pain in the ass. There are still new
installs of RH9 being carried out!
I think Thomas has exactly the right idea here - encouraging developers
to target what is actually installed on their users computers is good
which does mean that being able to assume DBUS is present is a long time
away. That doesn't mean we shouldn't use it. It does mean that making it
an essential piece of system infrastructure will just be ignored in
favour of custom config files OR will just cause pain for users who can
no longer install their favourite software.
I don't think that's an argument to avoid it for a config system. Far
from it. It just means we have to be realistic about timescales.
Anyway, there's no hurry. Outside of a few key pieces that could be
moved into XSETTINGS or pulled from elsewhere (like proxy settings) a
shared config system is nice-to-have but not essential.
This all comes back to the shared packageset/platform thing though.
More information about the xdg