Linked by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC
General Development In the Free and Open Source communities we are proud of our 'bazaar' model, where anyone can join in by setting up a project and publishing their programs. Users are free to pick and choose whatever software they want... provided they're happy to compile from source, resolve dependencies manually and give up automatic security and feature updates. In this essay, I introduce 'decentralised' installation systems, such as Autopackage and Zero Install, which aim to provide these missing features.
Permalink for comment 202150
To read all comments associated with this story, please click here.
Excellent
by siki_miki on Tue 16th Jan 2007 13:55 UTC
siki_miki
Member since:
2006-01-17

I agree with most of article points.
However I feel free to note some outstanding issues I'd like to see solved (don't know how much of it it is supported or not though in 0install):

-System dependencies:
What if app requires a specific daemon version (with specific protocol version), which is single & root on the system and that (version) isn't provided by the distro? Answer would be to avoid this kind of dependency or advice packagers not to target too high with version dependency. Useful is to have a way to try to fool program so that it at least installs and tries to rtun with older version. Area I even fear to mention are kernel features, init & udev scripts, etc. Probably this kind of packages is better handled by distro-specific packaging.

-Scripts are an issue. Obviously autotools' or deb/rpm scripts can't be used directly as they can mess up the system. They need to be modified to create specific temporary environment in which zero-installed app is supposed to run. Same goes for library environment, so when app which needs specific library is run, it should also execute specific script possibly required to set up the environment for that version of library (SDL env. variables as an example).

-Configuration: user should be able (via a friendly GUI) to modify which lib version is default for running his app with (whether it fails or doesn't is another problem). He/she should also be able to select 'variant' of a package he wants, as provided by different authors, such as distros, contributors or original code authors. It should also be possible to set defaults for which variant automatic installer will favour, including blacklist & whitelist support. Another wanted ability is to have specific tweaked lib/app version for specific distro, if 'vanilla' code is known to cause compatibility problems.

-Source. Users need ability to have custom compiled and installed software to his home directory, but which is registered into the package databases, or in 'overloading' local database. Perhaps autotools & co. should support this for ease of use.

-Local untrusted install. If user wants to have a version of software/lib from source which is new/unknown, he should be able to install it into his local home directory. Once root starts trusting this source, he can move it to shared repo.

-Binary compatibility. Another big topic which can make cross-distro compatibility harder. Autpoackager site has some interesting info about it.

-Optional dependencies. This needs support from multiple parties: linker support, packaging system support, and finally properly designed applications which will not malfunction if "optional" library isn'r present, but scale down their functionallity.

-Multiarch. although not mentioned, I hope x86 on x86-64 and packages with special compile options (mmx, sse,2,3 etc) are supported concurrently by zero-install.

All together, this system seems as best of a few devised to solve linux packaging fragmentation (and dependency hell). I certainly hope that distributions will support it as an alternative install system, as it shouldn't be too invasive addition. Certainly sounds like a good way to distribute newer app versions to older distributions, as well as various third-party stuff which isn't in distro repositories (perhaps even commercial sw). Not that deb & rpm are bad, but they don't solve many of above issues.

Edited 2007-01-16 14:00

Reply Score: 3