Posted by: Anonymous
on December 24, 2008 02:10 PM
While Nix has a somewhat novel approach to the problem their answer still leaves something to be desired.
I know it can do binary, too, but as the article states it was intended for source-based installation and inherits all of the problems involved with that.
As with the age-old debate about the merits of OS X style app bundles, what do you do about duplicated libraries (and other things)? Sure it's *useful* to have two different versions of Firefox, but now I also must have two copies of flash, two copies of each and every extensions I installed (and I must update them independently!). Multiply this out by a dozen programs and you start to encounter real pain.
Perhaps something similar to Nix which can also inter-relate things that are the same would be a viable solution. Imagine a kind of copy-on-write style of operation: As long as two apps rely on a particular version of a particular lib, one copy of the lib serves both apps. When one app is upgraded the 'new' app relies on a new version of the lib, the 'old' copy of that app relies on the old version, and the other app relies on the old version. When the other app updates to now rely on the new version, it re-points to the existing copy of the lib that was pulled by the first app. Basically, resolve dependencies as usual but, using Nix, don't break other things and smartly consolidate to the smallest set of files possible.
It would be hellishly difficult, I'm sure. You'd also really want some way to single instance configuration, where that makes sense, and make it version specific, where that makes sense.
One thing which I think would go a long way towards improving the situation: allow apps to link to libs by declaring a required set of exported symbols and not necessarily a specific version. Perhaps update the soname to include information about the compile time options that were used on the lib.