[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: zeroinstall-injector



On Fri, 27 Oct 2006 17:13:19 -0500, Richard Laager wrote:

> On Fri, 2006-10-27 at 11:10 +0000, Thomas Leonard wrote:
> 
> ... Thanks for your explanation. ...
> 
>>   http://0install.net/matrix.html
> 
> The one thing I found particularly interesting is:
> 
> "Conflict-free"
> "If program A requires an old version of a library, and program B
> requires a new version, A and B can both be installed and used at the
> same time. The system will never refuse to install one program because
> some other program is installed."
> 
> You gave an example of user-mode-linux and GnuPG.
> 
> Isn't this just an example of why properly using sonames is important?
> There's no harm in having both libfoo1 and libfoo2 installed, and if you
> need to upgrade libfoo1 from 1.0 to 1.1 to support an application,
> everything else that needs libfoo 1.0 will continue to work with libfoo
> 1.1, right?

It was actually "libreadline5" that needed to be upgraded. In an ideal
world, all versions of libreadline5 would be backwards compatible with
all earlier versions of libreadline5, but for some reason it wasn't in this
case. These things happen.

As another example (where soname versioning wouldn't have helped),
ROX-Filer 2.4.0 crashes when used with GTK >= 2.8.9 (2.8.8 is fine). This
is because GTK started emitting a particular signal slightly earlier,
before the filer had finished initialising a structure. Had GTK's range of
allowed behaviour been fully described, and had both GTK and ROX-Filer
been 100% bug-free, this wouldn't have happened, but in reality these
things will continue to happen from time to time.

To solve this, we had to track down the problem, fix it, redo our release
testing, and make another release very quickly. In a conflict-free system
like Zero Install, I could simply have marked ROX-Filer as requiring
"GTK < 2.8.9" in its XML feed. Then our users could have continued with
their existing version (no need to download the whole package again; just
refresh the feed) without affecting whatever program had caused our users
to install GTK 2.8.9 in the first place. We could then have spent a few
days or a week doing proper release testing.

So, in an ideal world, using sonames and multiple packages (libreadline4,
libreadline5) does work, and this is the solution Autopackage proposes,
but I don't think it's very realistic.

This is especially so when you consider packages less actively maintained
than those above. It took me quite a while to get FSV (fsv.sf.net)
installed on Debian recently as I had to compile a required library
manually and install to /usr/local. It used to install without problems a
few years ago (last release was 1999). It would be worth preserving these
older programs, by simply flagging them as needing older versions of the
libraries.

Hope that explains it better,


-- 
Dr Thomas Leonard		http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1



Reply to: