Re: RFS: zeroinstall-injector
On Thu, 26 Oct 2006 12:15:22 -0500, Richard Laager wrote:
> On Thu, 2006-10-26 at 14:39 +0000, Thomas Leonard wrote:
>> It builds these binary packages:
>> zeroinstall-injector - run programs by URL
>
> This probably isn't related to getting your package in Debian, so if
> this gets to be a larger discussion, we might need to take it off list,
> but...
>
> This looks interesting. How is this different than autopackage? Is
> there/ could there be some collaboration between your projects?
This is a fair bit of collaboration already (both sites link to each
other).
Both projects want to support decentralised distribution, so that anyone can be
part of the free software movement. i.e., a move away from the 'Cathedral'
model, in which users get all their software from a single distribution, to a
'Bazaar' model, where anyone can participate.
In more practical terms, having a separate person creating packages for each
different distribution, handling bug-reports, and pushing out security fixes
is wasteful duplication. As an upstream author, it is frustrating that one bug
is fixed in the Gentoo package, a different bug in Debian, and OpenBSD's
package is a year out-of-date, for example. It would make much more sense to
have both bug fixes applied upstream and available to all.
Both Autopackage and Zero Install require packages to be binary relocatable,
and to work on as many systems as possible. Autopackage has developed a number
of programs to help with this (e.g. binreloc and apbuild). These programs
also work well with Zero Install.
Where we differ is in the method of installation. Autopackage uses a method
based on that of MS Windows:
- The user downloads an executable script from a webpage and runs it.
- The script makes some changes to the user's system, hopefully resulting
in the program being installed without damaging anything.
There are two obvious problems with this approach:
1. There are no security checks built in to the system. There is no place to
check digital signatures or to warn the user about running software from
untrusted sites.
2. The script may damage the system (e.g. by overwriting files installed by
the distribution's package manager).
Like Debian, Zero Install uses a separate piece of software to perform the
installation:
- Packages must be GPG signed. The user must confirm that they trust the key.
I see the main role of distributions being to recommend software and keys,
rather than actually packaging the software.
- Each package extracts into its own directory. Nothing goes in /usr/bin, etc.
Whereas Debian prevents conflicts by having a single, tightly-controlled
repository and a well-defined policy for file locations, Zero Install removes
the possibility for conflicts in the first place.
Another difference is the way version conflicts are handled:
- Debian takes advantage of its centrally-controlled repository to ensure that
packages get updated together. E.g., if the new version of GnuPG requires a
new version of libreadline, but user-mode-linux requires an older version,
Debian will ensure that a new version of user-mode-linux is released so that
GnuPG can be upgraded.
- Zero Install installs each version of a program in its own directory, and
resolves dependencies at run-time. Therefore it will run the new GnuPG
against the new libreadline and user-mode-linux against the older version,
simultaneously. In a distributed system, where some packages cannot be
upgraded quickly, this is a big advantage.
In fact, even Debian suffers from this problem a little... the example is
exactly a problem I had a while back, forcing me to choose between having a
secure GPG to check programs' signatures, or a secure sandbox environment in
which to run them!
- Autopackage does not seem to address this issue, except to push for good
binary compatibility in libraries.
A matrix comparing various packaging systems (including Zero Install and
Autopackage) is here:
http://0install.net/matrix.html
A brief discussion of related systems is here:
http://0install.net/links.html
Thanks for your interest,
--
Dr Thomas Leonard http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
Reply to: