Re: package managers [was: FatELF patches...]

From: Mikulas Patocka
Date: Wed Nov 04 2009 - 13:46:50 EST

> > You can say that I should delete RHEL-5 and install Fedora, but that is
> > just that "upgrade one program" => "upgrade all programs" problem.
> Have you ever tried upgrading Windows because some program is incompatible
> with the current installation? ... That is indeed an 'upgrade all' procedure
> ... _If_ you're lucky enough to be able to reinstall your software.

Some Windows programs force upgrade, but not in yearly cycles, like Linux
programs. Majority of programs still work on XP shipped in 2001.

> Being able to upgrade at least Debian -- and others as well -- without the
> need to attend the computer is IMHO one of Linux' biggest wins.

When I did it (from Etch to Lenny), two programs that I have compiled
manually ("vim" and "links") stopped working because Etch and Lenny have
binary-incompatible libgpm.

If some library cannot keep binary compatibility, it should be linked
staticaly, dynamic version shouldn't even exists on the system --- so that
no one can create incompatible binaries.

> BTW: Wine has, like many others, the newest version of their software
> prepackaged for RHEL 4 & 5 among others at their site:

This is exactly the link that I followed and the last version for "RHEL 5"
is "wine-1.0.1-1.el5.i386.rpm".

> If all else fail the developers could go for statically compiled binaries in
> an executable tarball, which then handles the installation to /usr/local
> -Martin

Static linking doesn't work for any program that needs plug-ins (i.e.
you'd have one glibc statically linked into the program and another glibc
dynamically linked with a plug-in and these two glibcs will beat each


I mean this --- the distributions should agree on a common set of
libraries and their versions (call this for example "Linux-2010
standard"). This standard should include libraries that are used
frequently, that have low occurence of bugs and security holes and that
have never had an ABI change.

A distribution that claims compatibility with the standard must ship
libraries that are compatible with the libraries in the standard (not
necessarily the same version, it may ship higher version for security or

Software developers that claim compatibility with the standard will link
standard libraries dynamically and must use static linking for all
libraries not included in the standard. Or they can use dynamic linking
and ship the non-standard library with the application in its private
directory (so that nothing but that application links against it).

Then, software developers could make a release for "Linux-2010" and it
would work on all distributions.

You'd no longer need a [ distributions X programs ] matrix of binaries
and packages.

In five years, you could revisit the standard to "Linux-2015" with newer
versions of libraries and force the users only to five-years upgrades, not
yearly upgrades as it is now. "Linux-2015" should be backward compatible
with "Linux-2010", so an user doing upgrade would only need to overwrite
his /lib and /usr/lib, he woudn't even need to change the programs.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at