Message-ID: <Pine.LNX.4.64.0911041901090.26209@artax.karlin.mff.cuni.cz>
Date:	Wed, 4 Nov 2009 19:46:44 +0100 (CET)
From:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
To:	Martin Nybo Andersen <tweek@...ek.dk>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Ryan C. Gordon" <icculus@...ulus.org>,
	Måns Rullgård <mans@...sr.com>,
	linux-kernel@...r.kernel.org
Subject: Re: package managers [was: FatELF patches...]

> > 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: 
> http://www.winehq.org/download/

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

---

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

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.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists