Re: ZeroInstall & Package systems [Was: Re: Dock padding_pixels suggestion]

On 2007-07-10, Thomas Leonard <[email protected]> wrote:
> I used to have exactly the same problems with ROX-Filer, but now I just
> provide a Zero Install[2] feed for it. On most modern Linux distributions
> (including Ubuntu and Fedora), any user can just do:
>
> $ 0alias rox http://rox.sourceforge.net/2005/interfaces/ROX-Filer
>
> Then they can run it with the command 'rox'. It gets the latest binary
> version from my site, checks the signature using my GPG key and installs
> it. It also checks for updates from time-to-time. Have you thought of
> providing Ion that way?

No, I was not even aware of zeroinstall, and from quick glance, can  
spot a few real or potential problems:

  * Package creation seems to be a choice between WIMPshit and XMLshit, 
    judging from the packaging tutorial. No thanks.

  * How about dependencies? That's where these decentralised 
    packaging systems tend to fail compared to distros.
   
On the positive side, it seems to use URLs and local aliases
(that apply to binaries too!), instead of relying on a fully 
centralised naming scheme. It's not fully decentralised, though,
because DNS is centralised.

I've actually been thinking lately a bit about decentralised
packaging systems, and have been meaning to write about it
in the non-blog in more detail. In summary, the key 
features/principles would, however be:

  * Uses application directories (with relocatable binaries, so
    can be installed anywhere). That's absolutely necessary for
    decentralised packaging.

  * The package would not be the unit of dependency, but various
    capabilities, that packages (which are merely archive files 
    found in any way whatsoever) can claim to provide -- and any
    number of them. Some capabilities would correspond to individual
    programs ("Ion3"), and some would be more abstract and could 
    have multiple packages providing them ("libfoo API 1.2").
    How each capability is supposed to be provided is up to the
    capability author, and packages could be required to include
    a file specifying how it provides the capability (the library
    file name, executable name, anything)

  * "Cryptographically unique" capability names. The name would 
    e.g. be the public key signed with the private key of a keypair.
    Perhaps this would be the author's key, followed by a path,
    essentially creating a decentralised DNS (something I've also
    written about). 

  * Packages would use these cryptographic names (possibly locally
    aliased in some file to something more manageable) to refer to 
    their dependencies. They might also recommend a particular
    package implementing the capability. When some installed package
    already claims to provide a capability, but another package
    recommends something else, the user would be asked about it.

  * The same keypair can be used to prove that a package provides
    a capability by signing the package with the private key of
    the capability. Alternatively the capability author could
    provide a signed test suite that can be used to verify that
    a package provides the claimed capability.

  * The package system would be integrated with the build system.
    Presently there's a _lot_ of redudancy between distributions'
    package descriptions and autocrap. But a decent build system
    would include all the dependency information in an easily
    accessible format [1].

  * The package system itself does not specify how packages are
    found, but as single-click-install is too complex, and
    single-command-fetch-and-install is the way to go, presumably
    install tools could use some kind of search engine (google
    is the new DNS!) tailored for finding such package files
    directly, and let the user choose among the results. When
    the capability identifier is used to search, there should
    often be only one result, and even more often only one
    result that provably provides the capability, so the
    interaction needs should be minimal when installing 
    dependencies or upgrading known packages. 

    When the cryptographic identifier is not known, some
    method of scoring the (text/name search) results is needed. 
    Perhaps good old PageRank suffices. Additionally some
    instance that people trust could sign capability keys
    to correspond to some customary name for the capability.

Hmm... this was meant to be a summary... :) Well, there are
still some blurry details.

  [1]: http://iki.fi/tuomov/b/archives/2006/07/04/T21_20_46/

-- 
Tuomo