next level of

Mike Hearn mike at
Thu Jul 17 20:51:51 EEST 2003

> One possible benefit to trying to deal with these is to synchronize
> version jumps; historically, in one instance GNOME and KDE moved to a
> newer libpng at different times, and that caused a fair bit of mess
> for Linux distributions (and ABI incompatibility across
> distributions). So if we coordinated the libpng upgrade as part of a
> "desktop platform release" I can see it helping with that scenario.

As far as I know, the libpng issue is caused primarily by the fact that:

a) libpng is not parallel installable
b) ELF has old-skool symbol scoping rules.

(a) can and has been tackled, as the rather interesting tangle in my
/usr/lib directory shows. It should have been done upstream of course,
but perhaps in future can be used to hammer out
"emergency specs" for similar upstream oopsies.

(b) is somewhat harder, but basically boils down to implementing a
feature in the glibc dynamic linker that Solaris has had for years. I
don't know when it'll get implemented, but the lack of this feature
tends to cause a lot of binary compatability/versioning problems.

So, I'm not really convinced that there is a need to synchronize moving
between libraries like that. I think it's generally useful for
developers that want to be able to target a range of distros and distro
versions all at once, in much the same way that the LSB gives (primarily
server) developers a stable base on which to build. Those developers
tend to be commercial ones who don't like the idea of their software
being considered out of date 6 months after they released it.

On the other hand, there's a reason that a lot of desktop Linux stuff
has such fast release cycles, and that's simply because there's a lot of
catching up to do with the competition, a lot of stuff is kind of broke
(where "not standardised" often means broke imho) and so on. I don't
think it doesn't really make sense to pick an arbitrary point and say
"This is our platform for the next X years" when things are still moving
so quickly.

More information about the xdg mailing list