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.)

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, 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.