To view parent comment, click here.
To read all comments associated with this story, please click here.
So it's more of a distro independent packaging format that builds out it's own directory tree when the distro does not provide a dependency. That could be very intersting.
The other side of it may be how cleanly it managed uninstall but as a package manager that should really just be a matter of dragging dependencies back out if no longer needed by another zeroinstall package. It could offload the work to the distro package manager when applicable too so it's not duplicating the effort to maintain which packages need what dependencies.
For me, it's all about the minimal dependencies. Enough minimal install to get past the first boot then a very select list of packages which minimize the dependencies they drag in.
Granted, some of my more interesting toys need to be pulled in by subversion. Currently my update script does the distro packages then the svn branches so adding a third line for zeroinstall packages would be no biggy.
One interesting thing is that when you "install" a program, you're actually creating a launcher that runs 0launch. For example, to add a shell command "rox" to run ROX-Filer, you can do:
$ 0alias rox http://rox.sourceforge.net/2005/interfaces/ROX-Filer
That creates a script (e.g. ~/bin/rox):
#!/bin/sh
exec 0launch http://rox.sourceforge.net/2005/interfaces/ROX-Filer "$@"
0launch doesn't care whether the program is installed or not. It selects the best version of ROX-Filer, checks the cache, and downloads anything that's missing. So, I can take my little ~/bin directory to another machine and all my programs are available (installed lazily the first time I run them). And that works even if I move from e.g. a 64-bit system to a 32-bit one, or from Linux to FreeBSD.
(note: that doesn't mean it uses the network every time you run "rox"... if everything needed is already cached then it runs immediately)
Of course, you can also take the cache (~/.cache/0install.net) with you if you have more space or a slower network, or a shared network home directory. You can share a single cache between different architectures without problems. e.g. ROX-Filer would be downloaded again if you moved from Linux to FreeBSD because it's a C program (Linux and FreeBSD binaries would coexist in the cache), but Python programs would be shared automatically.
Edited 2011-05-26 12:38 UTC





Member since:
2005-09-17
That's a good question. What happens is that each program specifies what it needs in its XML "feed". For example, a program that requires libexpat1 >= 2.0 might say:
<pre>
<requires interface="http://repo.roscidus.com/lib/expat1">
<version not-before="2.0"/>
</requires>
</pre>
The expat feed says where to download various versions of the library, and also gives the name of the distribution package for various distributions (actually, the feed currently only gives one package name).
If you run the program on a system where the distribution's package of libexpat1 is installed and has version >= 2.0 then it will use that.
If libexpat isn't installed through the distribution (or it's too old) then 0install may download a newer version to the 0install cache and run the program using that (without affecting other programs, which continue to use the distribution's version).
Or, it might use PackageKit to install or upgrade the distribution package, if a suitable version is available (requires confirmation and admin access).
As the author of the program, all you need to know is that you require libexpat1 >= 2.0. You don't need to know the different names that different distributions use, or whether a 0install package for it will be used.