Packaging systems should be comprehensive

January 14, 2010

I have a number of peculiar opinions about packaging systems in general. One of them is that if you have a good packaging system, you should be able to manage your machine entirely through it; every modification that you need to make should be doable as part of a package.

(Okay, not quite every modification; I'll exclude files that are in constant flux outside of your control, like /etc/passwd and /etc/shadow, and operations like rebooting the machine due to new kernel installations.)

This is a large systems attitude. If you're running a lot of machines you want to manage them through one mechanism, not many, and it needs to be a mechanism that can be mostly or entirely automated. You almost always have to deal with the packaging system to some degree; the logical conclusion is that you should be able to do everything with the packaging system. Further, if you are managing a lot of machines you have a great deal of configuration elements that are common across all of them (or subsets of them), and this sounds exactly like a package that you install on all of those machines.

The other large systems choice is to have nothing to do with the package system at all; to do everything outside of it, to control it with your real management system, and to never interact with it. There are several serious drawbacks of this approach, since not only are you throwing out all of the work the packaging system does to maintain state information and make operations safe, you're actively going behind its back and fighting it. When you and the packaging system disagree about who is in charge, sooner or later both of you lose.

(However, it is much easier to take this approach, especially since it doesn't require the cooperation of the package management system. Hence it is quite popular for system management programs.)

Accepting this idea has significant implications for the features your packaging system needs. For that matter, so does thinking about this issue but disagreeing; if you reject comprehensiveness but accept the problem, you need to design a package management system that (to put it one way) does not believe that it's in charge.

(My strong impression is that current packaging systems have not really thought about this; instead, they have opted to believe that they live in a world where they are more or less in charge and that they can fix up the gaps with spackle and hand-waving.)

Comments on this page:

From at 2010-01-14 13:59:28:

I think you're misapplying the cornerstone of object-oriented software development, in which methods and data are coupled, to systems administration, where the paradigm doesn't really fit.

In software parlance, this idea violates what's called the "separation of concerns." Here, you can think of concerns as responsibilities. For the base operating system, packaging is the responsibility of the vendor, and configuration is the responsibility of the organization implementing the vendor's product. In most circumstances, unless you need to apply specific patches or change specific compilation options, you don't really want the product and the configuration to overlap where they don't need to.

It's true that you want to use one tool to do everything, but I don't see a compelling argument for why that tool should be the package manager. It seems much more logical from my perspective to wrap the package management functionality into the configuration management tool, rather than trying to shoehorn configuration management into package management. This is the approach taken by tools like Cfengine or Puppet, where most people will fold package prerequisites into the configuration management functionality so that the tool installs the requisite package first, and then applies the appropriate configuration.

Logically, you design a server configuration, and pick the packages to perform that function. You don't pick a bunch of packages at random and say, "hey, what cool stuff can I do with these packages?" It logically follows that the packages are subordinate to the business requirements imposed on the server, not the other way around.

Besides, if you're designing your configuration management in a well-structured way, it should behave more or less the same way on all platforms. It becomes much more difficult to rebuild a dozen packages when changing a configuration file than it is to simply alter a template and let your configuration management tool handle the rest.

While release management and configuration management do have substantial overlap, ITIL and other process frameworks draw important distinctions between them for a reason -- they're fundamentally different activities, which have fundamentally different implications, and often they're handled by very different workflows within the organization. When you're talking about systems management and maintaining responsibility for files living on a filesystem, you have to keep a distinction between software and configuration, between code and data, just like you already keep a distinction between static and volatile data. There's no compelling reason to combine the disciplines of release management and configuration management into a single entity when the goals and methodologies of the two are so different from one another.


By cks at 2010-01-15 01:00:34:

I quite agree that you don't want to be rebuilding the vendor's packages just to roll your changes into them. That's why the package system shouldn't make you.

The problem with using a separate configuration management tool is that a good CM tool must reinvent and re-implement a great deal of functionality that a good package management system already has. I think that the amount of CM functionality that needs to be added to package management is smaller than the reverse.

(In my opinion, a good CM tool should be able to handle dependencies, versioning, and upgrades, and be able to tell you where a random file on your system came from and whether it's been changed from what it should be.)

The drawback to CM in the package management system is that it's not cross-platform. On the other hand, it doesn't hurt cross-platform CM (and it immediately helps people who only run one platform); at the best, the cross-platform CM can be an increasingly thin layer over the native CM capabilities.

Written on 14 January 2010.
« One reason why you should not let people register other people
Packaging systems should support overlays »

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

Last modified: Thu Jan 14 01:36:54 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.