posted by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC



We want to combine the openness and freedom of getting software from upstream developers with the convenience of binary packages, dependency handling and automatic updates. We want to allow users, administrators, programmers, QA teams and reviewers to collaborate directly.

Users of traditional Linux distributions can only easily use software from their own distribution. This is inefficient, because popular software is packaged over and over again, and limiting to users, because less common software is often not available at all. Adoption of new software is hindered by the need to become popular first, so that distributions will carry it, so that users will try it, so that it can become popular.

If we no longer have a distribution to ensure unique naming of packages then we must use a globally unique naming scheme. Options include UUIDs, content-based digests, and URLs.

We must also ensure that packages cannot conflict with each other, especially if we permit mutually untrusting users to install and share programs. We can avoid the possibility of conflicts by keeping each package's files in a different directory and naming these directories carefully.

Dependencies can be handled by letting go of the idea of having a single, system-wide version of a program installed. Instead, dependencies should be resolved on a per-program basis.

To allow our packaging system to check for updates and fetch dependencies for us we must provide the information about available versions in a machine readable format. Several XML file formats are available for this purpose.

For a decentralised packaging system to be used for more than the occasional add-on package, it must be able to share downloads between users to save bandwidth, disk space and memory. This can be done either by having a trusted process perform the download, or by having a shared directory which will only store directories with names that are cryptographically derived from their contents.

The are many security concerns to be addressed, for both traditional and decentralised software installation. We should avoid running scripts with more privileges than they require, and avoid running them at all if we can. We must provide a user interface that makes it difficult for users to accidentally install malicious software, and allow users to check that software is genuine in some way.

Free software requires the ability to make changes to programs. We should be able to get the source code easily, plus any compilers or build dependencies required. With conflict-free installation, we can get better binary compatibility and more reproducible builds, since we can build against selected versions of dependencies, even if these are not the versions we normally use when running.

Finally, we saw that it is often possible to convert between these different formats, with varying degrees of success. Even if most users don't start using decentralised packaging right now, but continue with their existing centralised distributions, these techniques are useful to help the process of getting packages into the distributions in the first place.

[Digg this story!]
Table of contents
  1. "Introduction, Use Cases, Traditional Distributions"
  2. "Naming, Conflicts"
  3. "Avoiding Conflicts, Dependencies"
  4. "Publishing Software, Sharing Installed Software"
  5. "Security"
  6. "Compiling, Converting Between Formats"
  7. "Summary"
e p (8)    76 Comment(s)

Technology White Papers

See More