A simple thing that every package management system should have

September 11, 2010

Here's something that I was reminded about recently, most directly due to doing some work on a Solaris machine (although the general issue has come up before).

Every single package management should provide a way to save the name and version information for all packages and patches (if you use them) that are installed on a system, and also a way of easily setting up another system with exactly that set of packages and patches. This should be done through straightforward command line tools; it should certainly not require installing or adopting a great big system management system, using a web frontend or management console, or whatever. Both of these tools should be installed by default.

Ideally these tools would produce and consume plain text in a straightforward format. If you insist on making your version of these tools use XML or some other private database format, you need to also provide tools that dump a readable form of this and report the differences between two package states.

(Sooner or later sysadmins are going to want both abilities.)

By the way, if your operating system or Linux distribution can't always recreate a given set of package versions for whatever reason, you cannot really aspire to being a 'production' or 'enterprise' ready operating system. One common reason is feeling that some updates are mandatory and so not giving people any option about those updates when they install new systems; another is removing old versions of packages or patches when newer versions are released.

(This means that I don't think that Fedora is production ready, since Fedora deletes the binary RPMs for obsoleted updates from mirrors. You can get around this by maintaining your own local Fedora mirror that never deletes anything. Note that I understand why Fedora does this, and being 'production ready' in this way is not part of Fedora's goals anyways. Red Hat Enterprise does keep all package versions around forever for exactly this reason.)


Comments on this page:

From 70.95.101.194 at 2010-09-11 04:43:21:

Unless I'm missing something, both RPM and APT allow you to do that already, with the standard tools they come with:

rpm -qa gives you:

bzip2-devel-1.0.3-4.el5_2

You can pass that list across to another system and just do a straigt: cat rpmlist | xargs yum -y install

Provided the version is still available in the repository (should be for RHES / CentOS) then it should install.

Or alternatively the --qf flag allows you to specify a format using printf syntax, e.g.:

rpm -qa --qf '%{NAME} %{VERSION}\n'

which will list the installed packages in one column and the version in a second. If you're maintaining strict repository practices (i.e. all packages installed from a repository rather than downloading RPMs separately), and have all machines patched up to date, provided you copy the repo settings across to another machine you should just be able to output only the package names to a file and do the same cat | xargs trick as above.

Under Debian / Ubuntu dpkg -l will give you a columnar list of packages with name and version in separate columns. apt-get will allow you to pass it specific versions to install. For example on my Ubuntu desktop I've got installed eog version 2.31.91-0ubuntu1. To get apt to do the install of that version, take the package name, append an equals sign followed by the version:

apt-get install eog=2.31.91-0ubuntu1

From 87.198.25.32 at 2010-09-11 07:03:47:

A better debian solution is to use dpkg --get-selections and dpkg --set-selections to restore them. Although it doesn't preserve version numbers unfortunately. However a debian release generally won't ever modify a package (except for security updates) so the effect is (usually) the same.

Yes, there is some handwaving here :)

By cks at 2010-09-11 12:08:08:

The dpkg approach isn't a solution because sysadmins do very specifically want the exact package version that is installed on system A to also be installed on new system B.

RPM, Yum, apt, and so on give you the pieces that you could use to build this (provided that the distribution preserves old now-updated packages in their repository), but I don't know of anyone who actually provides a canned solution to do it. Being able to assemble something isn't quite the same as being able to run two commands and being done.

(Note that plain rpm -qa is not good enough; you really want to put the architecture in there too.)

From 65.172.155.230 at 2010-09-15 10:30:51:

With yum there is also:

yum-debug-dump and yum-debug-restore

...for former is in RHEL-5, but the later didn't quite make it. For RHEL-6 there is also "yum version" to check that two machines are "packaging identical".

Written on 11 September 2010.
« Go's network package and IPv6 (and my ideal version thereof)
One aspect of getting used to modern version control »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 11 01:38:59 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.