Distro non-wars... was Re: [plug] Red Hat

[Craig Ringer]

> As you say, the situation looks a lot more challenging than I had thought.
> Basically, if one created (or in user-land, downladed) a binary it would
> be pretty much locked into a specific distro, or at the least, into a
> specific set of underlying libraries and APIs.

Not entirely - the libraries are all, by and large, mostly the same 
between distros. It's that "mostly" that's the bugger - look at qt on 
Red Hat for an example of something that gives developers headaches. On 
the flip side, trying to write programs that work over several years 
worth of linux releases can be quite hard, since there seems to always 
be something breaking binary compatability - gcc-3 transition, g++3.2 
transition, glibc upgrades, etc.

Another fun thing is that even between different RPM based distros, some 
distros call the same library by a different name in the package 
management database - so you get an RPM that requires "libblah1" and the 
distro provides it, but called "blahlib1".

Just to make life even more fun, sometimes different distros have 
different sonames for the same library - libblah.so.0 under Debian might 
be libblah.so.1 under RH ... then debian updates to the next 
binary-incompatable version of libblah and calls it, logically, 
libblah.so.1 ... *arrggh*.

The latter issue should be helped by the efforts of the LSB, but the 
constantly transitioning incompatable libs and compilers, plus the 
varying patches the different distros make to things, are quite bad 
enough. Especially when just dealing with the different way distros do 
runlevels, firewalling, and other small stuff is quite tricky enough. To 
top it all off, one distro will have only gtk-2.0.ancient (debian) while 
another will have only gtk2-4.x (debian sid/gentoo), etc - versions 
change fast, and trying to make an app work nicely on all of them is 
going to be hard.

This is probably part of the reason why well packaged commercial apps 
are so rare. You can't package once, run anywhere - so they resort to 
other methods. Things like:
- shell script installers that may or may not tell you what they'll 
do/are doing
- static binaries so they'll actually run on a variety of distros
- 'just untar it' packaging (not too bad in many ways)

Then again, it can be done right. Look at Sun - they've packaged the JRE 
and JDK universally (well, not in Debs but I can't blame them). I'm sure 
it's not perfect, but it's a darn sight better than many other things.

Acrobat reader isn't too bad either, though I'm REALLY tired of having 
to edit /usr/local/Acrobat5/bin/acroread to add 'export LC_ALL=en_AU; 
export LANG=en_AU" to stop it crashing due to a unicode locale. Is it 
really that hard to just add a check in the top of the shell script as 
distributed instead of asking the user to change their locale as Adobe do?

This doesn't just go for commerical apps, though. OpenOffice is a good 
example of an app that's hard to package for Linux because of the huge 
variation in distros, hence the 'untar in /usr/local' approach it takes. 
That's not bad, but it would be nice to be able to make packages that 
just worked for all distros. I'm sure it jumps through a fair few hoops 
to get binaries that run on all of them, too.

Basically, IMHO all this stuff is holding Linux back. Much of it is just 
silly, like varying names for packages (lots of which is just historical 
baggage now) and different sonames. Other issues are trickier, like 
vendors patching major libraries heavily (*cough*RH*cough*) and 
different package management systems.

Hopefully this will improve over time, but the vendors will have to deal 
with compromise - possibly breaking backward compatability of packages 
to fix issues with sonames and package database names. It needs to 
happen, but it won't be easy.

Craig Ringer


_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug