Minutes of the second WP2 meeting, held in PPS on February 28th

Please feel free to improve this preliminary version by any means.

  • Main.AssafSagi presented a survey of the state of the art in package management and dependency handling. The presentation is available here?.
The outline of the presentation is as follows:
  • A survey of 4 popular package managers: urpmi, apt, yum and portage. Existing package managers today handle dependencies by reading them from a specified file/repository. These are called "declarative dependencies".
  • A summary of the problems found today in the state of the art. These can be categorized into 3 groups as follows:
  • Lag - It can take a few months for a program to be packaged for a certain distribution. Due to this lag unofficial packages are created by independent packagers with no formal way for users to determine their "maturity" level.
  • Dependencies - Dependecies are declarative today and hence sometimes inaccurate. A referenced dependency must be an existing package or file name in the distribution. Their installation status on the user's system is checked through the package manager's repository and not directly in the system.
  • Incompatibility - Packages made for a certain distributions may not install correctly on another, due to the many differences and nuances between the different distributions.
  • A list of some related tools, which aim to solve or ease some of the problems summarized previously. The tools surveyed were: Alien, AutoPackage, CheckInstall and ldd. Some tools take a rather different approach to packaging and installation, such as: ZeroInstall, GoboLinux and A-A-P.
  • Suggestions and directions for future research. A general architecture which can help solve some of the problems both in Work Packages 2 and 4 was shown. The architecture consists of a P2P overlay network connecting the different users, hence creating a community. Services will be provided by applications built on top of the overlay network. Those services will include:
  • Notification - Users will subscribe, by a content-based subscription system, to events related to new/updated packages they're interested in.
  • Pushing Updates - Users who are interested in new/updated software will organize themselves to a multicast tree and get the updates in an efficient manner.
  • Completion - Users who missed certain updates or parts of them will use the overlay network to find peers sharing those missing updates.
  • Main.RalfTreinen gave a presentation of Debian, and of some aspects of its packaging systems that are relevant for WP2. Slides are available, as is a collection of useful links to documentation about Debian packages. Besides what can be seen on the slides, we had a look at how the packages =texmacs= and =hevea= are done in Debian.
Some points that were discussed at hand of these examples:
  • A source package may spawn off several binary packages
  • Binary packages may have circular dependencies
  • The control information of a binary package is derived at package building time from the control information contained in the source package (file =debian/control=). In most of the cases this means that
packaging helper scripts replace variables in the control information by values obtained when buidling the package, for instance the set of all packages containing libraries used by a package (obtained through =ldd=, and subsequent lookup in the package data base to determine the name of package a library belongs to). However, it is in principle possible that the main package compilation script (file =debian/rules=) manipulates directly (through =sed= etc.) the control information.
  • One important consequence of this is that the name of the package and its version number do not uniquely determine all its attributes. Name and version number are given by the
source package (first line in =debian/changelog=), but for instance the exact dependencies of a binary package may depend on the the versions of the libraries available on the machine the binary package was built on.
  • Any distribution contains at most one version of any package (in case of the =unstable= distribution, this version may be different depending on the architecture). A distribution is defined by the contents of the according =Packages= file, however, the different distributions share common directories for the packages (this is the _pool_ structure introduced for the _woody_ distribution).
  • One thing we would like to have, but which currently is not posible in debian, is to have real constraints in the control file of a source package. The control information of the binary package would then still be obtained through instantiation, but it would give much more flexibility. For instance (with a slight derivation from debian syntax, for the sake of clarity):
Source-Package: hevea
		Builds-Depends: ocaml-compiler (version n)

		Binary-Package: hevea
		Depends: ocaml-runtime (version n)

		Constraint: n >= 3.0
%META:FILEATTACHMENT{name="StateArt.pdf" attr="" comment="" date="1110100883" path="StateArt.pdf" size="516563" user="AssafSagi" version="1.1"}

{metadata}

Type Meeting

Topics Wp2

{metadata}

Version 1.11 last modified by StephaneLauriere on 14/11/2005 at 09:42

Comments 0

No comments for this document

Attachments 1

PDF
StateArt.pdf 1.1
PostedBy: RobertoDiCosmo on 18/05/2005 (504kb )

Creator: RalfTreinen on 2005/05/12 22:04
Copyright EDOS Consortium
1.1.1