Package system for Plash
Contents
Status: implemented
Aim: Plash should provide a package system that can set up a package and its dependencies in its own sandbox. Like Zero-Install, it will allow applications to be installed from different providers and using different versions of libraries. Packages will not need to be installed as root. The tools will install packages from MiniDistro.
The package system will be based on the Debian package system. It will be possible to install packages into a sandbox from a Debian repository based on an apt sources.list file using the Plash package tools. However, it will have the following differences from the Debian packaging system:
- Plash's package tools will install packages into a sandbox from outside that sandbox. In contrast, dpkg and APT run inside the system they operate on. We will provide our own set of package tools, which may or may not share code with dpkg/APT.
- We may extend the packaging system. e.g. Add an alternative representation of .deb files, or add fields to the Packages index.
Plash's package system will be loosely equivalent to creating a chroot environment for each application using debootstrap and installing packages into it -- which is a common practice for chroots and Xen virtual machines. The package tools will make this more efficient by sharing immutable files between sandboxes rather than creating copies (as debootstrap does).
Front end
The package tools should provide a GUI similar to those provided by Polaris and CapDesk, and outlined in Interaction Design for End User Security. Installing an application should create a link for launching it (i.e. in applications menu), set up file associations, etc.
Features of Debian packaging system
- APT sources.list file: lists repositories to use. Effectively provides a simple way of merging repositories, with ordering of entries determining priorities.
- Repository: consists of a Packages file, signed with the repository's key. One can save a snapshot of a repository by saving the Packages file, though this is not commonly done, because dpkg/APT don't expose an interface for using them.
- Package: a .deb file. A Packages file refers to .deb files by their hash (a secure reference).
- Package name
- Dependency
There was a debate in Debian a while ago on whether to sign the Packages file with a Debian-wide key as well as having individual packages signed by individual Debian developers. The former makes more sense from a user's point of view, because their relationship is with Debian as a whole, not individual Debian developers. Debian did end up signing the Packages file.
Debian lacks some features that are useful for creating a derivative distribution, needed for MiniDistro:
- Doesn't track branching of packages. See Conary's package versioning for one way to deal with this.
- Doesn't allow a Packages file to refer to another server. The Filename field must be relative to the repository's top-level directory?
Other package systems
Zero-Install
See: http://zero-install.sourceforge.net/
Comparison of Zero-Install with planned scheme:
- different package validation (security) model
- different dependency model
- ZI works by adding directories to LD_LIBRARY_PATH and other path environment variables.
- Note that environment variables are only one possible binding mechanism. For example, another mechanism would be to union all the selected packages' library directories over /usr/lib. Plash is an obvious candidate for doing this...
A Zero-Install "feed" is specified by a URL, and may list multiple versions of the package. Each version can provide a list of other feeds as dependencies.
Feed URLs are not secure references. They do not contain any hashes or public keys. The feed file retrieved from the feed URL is signed and must be checked against a set of "trusted" keys. If the feed's key is not in your trusted set you are asked whether you want to add it.
You have to declare trust for authors/packagers of all dependencies. This does not scale. This is not good because you have no basis for the decision of whether to trust a source; you have no direct relationship with creators of dependency packers.
- There are also key databases, which list trusted keys. You could have a relationship with a key database. However, the only currently-existing database is rather low security, simply noting that a particular key fingerprint was announced on a public mailing list on a certain date.
Keys in Zero-Install are either "trusted" or not. They are not marked as trusted for a specific purpose. This can create a confused deputy situation. This is not a problem with Zero-Install as it stands, because Zero-Install packages all run with the user's full authority. If sandboxing were added, the inability to distinguish kinds of trust would be a vulnerability.
- This was changed in version 0.27. Keys are now trusted only for single domains.
Zero-Install does not provide a way to refer to an immutable package. There is no way to reproduce a configuration.
- 0compile can save and restore build dependency configurations. This is automatically added to binary packages it creates.
- Since version 0.27, this works for binary package selection too (0launch --get-selections and --set-selections).
Zero-Install does not make it easy for a third party to replace one package in a set of dependencies. To do this you would need to copy all the feed files and re-link them.
- Not true: use "0launch --feed" to add a feed locally that overrides an interface (specified by the interface URL). Does the override happen globally (per-user)?
- It's per-configuration profile. Typically, that's per-user, but you can use alternative configurations by setting an environment variable.
Zero-Install doesn't have a tool to import a Debian repository's packages en-masse. You can convert an individual package but you'd have to follow the dependencies yourself and create a feed for each one.
True. The deb2zero program needs to be made smarter: http://0install.net/deb2zero.html
Zero-Install packages typically have undeclared dependencies on libraries and tools that are assumed to already be installed on the host system. For example, dependencies on libc and Gtk. Though one could package those dependencies within Zero-Install too, the objection to this has been that it would result in duplicates of already-installed data being downloaded and installed, wasting network capacity and space. For Plash's package system, we will largely disregard this objection and make copies anyway, although it will be possible to check /var/cache/apt/archives.
- Since 0.28, 0launch allows using native packages as additional candidates.
Klik
Conary
See: http://wiki.rpath.com/wiki/Conary
Conary is a monolithic packaging system, in the sense that packages are installed system-wide.
Package repositories may be branched. Conary is intended to make it easy to produce derivative distributions. To that end, it has a fine-grained dependency system. Dependencies are calculated automatically in many cases. Packages may declare dependencies on Python and Perl modules, shared object version symbols, etc.
Conary's scheme for package branching is closer to CVS/SVN than Git. Package version strings encode the branching history. Branches are declared (as in CVS/SVN), not inferred (as in Git).
A Conary repository does not provide a package list file like a Debian package repository does. It appears that Conary repositories are always dynamically queried. Package information is stored in a database, and a special server program is required. Conary repositories can't be served from a dumb HTTP server.