we need a spec for handling mediums

[Mike Hearn]

> 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
> another.

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.

Examples:

- 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 
Ximian Gnome

- 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.