Submitted by “Zero Install is one of the more promising alternatives to native package systems for Linux distributions, such as RPM and Debian’s dpkg. Originally developed by Thomas Leonard, who works in the Department of Electronics and Computing at the University of Southampton, it begins with a criticism of existing package systems the difficulties of using them, and is built to provide an answer to the problems raised by the critique. However, like other alternative package systems, it faces the problems of winning acceptance from the major distributions and fine-tuning its features.”
I vote for big fat executables with no dependencies. Woo hoo!
I think I’ll be staying with Gentoo and Paludis, thank you very much.
I vote for the optimal solution, no matter how challenging it might seem. A perfected centralized package management system will be the ultimate software management solution. You can’t beat a system that catalogs all known software packages; allows one-click installation, upgrade, and removal of all of them; and provides automated update facilities. All without excessive library bloat, and with a certain degree of assurance that the package is not malicious and has been tested on your system.
Look how good today’s package management solutions have gotten. They hardly ever fail, and even upgrading to new repositories is usually hassle-free. We’re around 99.5% of the way to our optimal solution, so why should we change gears and settle for less?
…though I’m wondering about the fundamental advantages of this over a method like Klik, for example.
From what I understand, Klik requires a “klik://” url and runs from a self contained “disk image” basically. With the default kernel configs on most distros, you can only loopmount 8 images at a time on a system… could be an issue in the future.
Out of the standalone installers, I actually really prefer “Autopackage”; you can install apps for a user or system wide, and just works by double-clicking on the package. Then you have an “Add/Remove Programs” tool that does exactly what it says. It’s all very GUI, but I believe it falls back to text-mode if you’re in the console.
However, there’s nothing that beats just downloading a deb and double-clicking on it in Ubuntu/Debian (thanks to GDebi).
Klik and 0Install only install “per user”, Autopackage can do either, DEBs can only be installed by an Admin though. Debs can be kept updated automatically if you add the repository (if the creator provides one)… so can 0Install apparently. Autopackage and Klik cannot.
Basically, they each have their place, but none are 100% perfect.
Klik and 0Install only install “per user”, Autopackage can do either, DEBs can only be installed by an Admin though.
The goal is to allow automatic and safe sharing of packages installed by multiple users, as explained here:
http://www.osnews.com/story.php/16956/Decentralised-Installation-Sy…‘>
However, even without this 0install will install system-wide (to /var/cache/0install.net) if run as root, and it won’t execute any code from the package while doing so (no preinst.sh scripts, etc), so it’s no worst than the alternatives.
Edited 2007-02-17 08:34
http://0install.net/matrix.html
Basically, it’s like Klik but:
– The recipes it downloads are XML files, not shell scripts (this is similar to the difference between tar and shar files).
– Zero Install downloads are GPG signed.
– Zero Install is decentralised: you need permission from the Klik maintainers to distribute a Klik package. You don’t need anyone’s permission to distribute with Zero Install.
– Zero Install can check for updates automatically (by default once a month, but configurable). Klik requires you to check for updates yourself.
– Zero Install handles dynamic linking. This allows upgrading a library to benefit multiple applications, and saves space and bandwidth. It also lets you use a different version of a library if you want. Klik bundles all dependencies into the package (Zero Install also supports this mode of operation if desired).
– Zero Install can share downloads between users safely, using cryptographic digests (only partially implemented at present, though).
– Zero Install supports compiling from source if you want, though not many packages support this yet.
– Zero Install lets you download older versions or programs or libraries. Klik only provides a single version for download, although you can keep using older versions once you’ve got them.
– Zero Install is fully OSS. Only the Klik client is.
– Klik runs the ‘intellipatch’ script on downloads, which does a search-and-replace for filename paths in binaries (simple text matching) and changes them. This allows some programs which aren’t built to be binary relocatable to work. Zero Install doesn’t support this, and requires binaries to be relocatable in the first place.
– Klik has many more packages available right now.
“fundamental advantages of this over a method like Klik”
In addition to Tom5’s good points:
– ZeroInstall is platform independent, Klik only runs on Linux.
My vote would go for a distro independent package manager that supports automatic dependency resolution, dynamic libs, auto updates, integration with other distro specific package managers and integrates with some kind of emulation framework (so you could ship say DOS games as packages).
It’s not going to happen though…
distro independent package manager that supports automatic dependency resolution
…is impossible because different distros maintain different dependency maps. This is really the fundamental problem with
all these types of thing. To avoid clashes, you have to maintain parallel systems. The package manager isn’t the problem, it’s the repos, with their webs of dependency.
DEBs can only be installed by an Admin
I’d be surprised if dpkg couldn’t be set up to be used by an unprivaledged user in a sort of chroot. Though how useful it would be in that situation is another matter.
Of course, ther will always be a security risk when installing software. Although install scripts could cause all manner of trouble, they rarely need do anything more than copy some files. And when they do do more than that, they usually need root privileges.
Browser: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240×320)
And the sollution has been known for ages:
Don’t depend on an implementation (i.e a package)
Depend on an interface (Closest thing toady would be the virtual packages that some distros uses)
We are using. If C/C++ was more tolerant to changed or added function parameter here and there, and the ABI’s were not so incompatable between them (gcc-2, gcc-3, gcc-4 had some incomatibility problems), then it would’ve been easier.
Or if it was the case, as the OpenStep/NextStep guys did it with Objective-C – you can override any class if you want runtime, or you can extend any class you want with new function members (no variables).
But yet, most of the OSS software is written in C and C++.
Pity.