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
