Posted on Sat 27 February 2016

questions for packaging systems

First, some history. Then, some questions largely of interest to system administrators.

Once upon a time [UNIX] software distribution was simple. Your operating system came as a huge blob over which you had no control. Sometimes there would be updates. Sometimes the update would require a reinstall, sometimes not. Additional software came in similar blobs, “managed” in a similar way.

For a while, you needed to compile anything you wanted yourself. Figuring out dependencies was hard, so people adopted makefiles and then autoconf. Autoconf could figure out what sort of system you were running, adapt to various inconsistencies and then even figure out what libraries you were missing. Building a nontrivial system was, well, nontrivial. If you were missing a key feature, you would need to stop and build something else, which might in turn require an update or hopelessly disable some feature in another system that you were quite fond of.

Automating this mess was a good idea, so people did that. The BSD Ports system, among others, was a huge library of source code stubs that declared dependencies and could download code and compile it for you. The Packages system then arose: software which declared dependencies and was already compiled.

(Over in Windows Land, you had a single operating system with just a bare handful of versions, so every software installation process had relatively simple assumptions about what was available and what would have to be provided. 22 high-density floppies? Everyone greeted the arrival of CDs as a lifesaver.)

Modern packaging systems need to be able to answer the following questions convincingly:

  • Is the software integrity intact?

Are the bits that I asked for the bits that I received? Did the download happen over an encrypted link? Can I verify the integrity pre-install and post-install? Manually and automatically?

  • Is there an automated system for updates?

Can I get a timely notification of an update? Is the notification protected against fraud? Can I install packages without answering questions interactively? Can I install updates automatically? Can I prevent one or more updates while letting others go through?

  • Are dependencies automatically tracked and installed?

Is there a clear difference between required dependencies and suggested add-ons? Can I set a preference to automatically install all the suggestions? If a suggested package install fails, does it abort the install or upgrade of the requested package?

  • Are included component libraries tracked?

If you have a statically linked or co-packaged library – that is, a dependency built in to the same package – is there visibility into that from the outside? Can it be tracked for security or feature updates like the main package?

  • Is the responsibility for packaging and updates defined?

Does your development team overlap with your security team? Do they know their responsibilities? Are they documented and visible to the end user?

  • Are the tools for creating and maintaining repositories available and well documented?

Can I create a secure mirror of the upstream repos? Can I create a local cache? Can I create and advertise a third-party repo for distribution to other users? Can I create a local repo just for my own use? Is the source of a package clear to the end-user before installation? After installation? Can my packages conflict with upstream packages and replace them? Can I selectively set priorities per-package? Per-repo?


© -dsr-. Send feedback or comments via email — by continuing to use this site you agree to certain terms and conditions.

Built using Pelican. Derived from the svbhack theme by Giulio Fidente on github.