managing configurations, not packages

Michael Gratton mike at
Wed Dec 11 16:53:10 CST 2002

stephen white wrote:
 > The debate's still going in private email, so I thought I'd post what
 > I think the alternative is, for those of you interested in systems
 > management.

Err, and then I replied:

 > It is not necessarily bleeding edge if it's from CVS... you can
 > download from release tags.

But why bother when you can install the same release using the Debian 
package? If it's only to tweak some compile-time options, then use 
apt-src which compiles the software as you like it and builds the 
package for you, which you then install.

 > You're making this into a straw man debate, where you make up
 > ridiculous solutions then demolish them.

Okay, yes, that was bad form. I was trying to suggest some alternatives 
to using a central db for package management, but to be honest I can't 
think of any better ways of doing it.

Can you offer some better alternatives?

 > sendmail configured for SMTP is operationally a different program
 > than sendmail configured for UUCP. This is why you see
 > sendmail-smtp and sendmail-uucp in the Debian packages list.
 > This is an example of where the packaging system had to bend to
 > cope with the reality of the situation.

If the only difference between the two is configuration, then it's just 
been badly packaged. If there were significant compilation differences 
between the two then I would argue that they are different programs, or 
at least incompatible variants and so *should* be packaged separately.

As an aside, the separate sendmail-foo packages don't exist anymore, the 
one sendmail package does both SMTP and UUCP.

 > Dividing packages by program is subtly different than dividing
 > packages by functionality, and this is also seen in the Debian
 > packaging system with dummy packages like "x-windows" that
 > conceptually group multiple actual packages.

Again, I think this issue has been resolved. Dummy packages have been 
replaced with virtual tasks and packages, which is a much better way of 
handling this.

 > It's been a while since I thought about this issue in depth, but I
 > recall that I was in favour of probing the filesystem to see what
 > programs were installed, then retrieving configuration files based on
 > the combinations.

The first big problem with that approach is that it's just not robust 
enough. If someone accidently deletes a file used by a package, there's 
no longer a record of that file and any package-related information that 
would normally be obtained from it is lost.

For example, if I stored the package version and MD5 checksum on the 
file /usr/bin/foo itself, or had to obtain the version by executing 
/usr/bin/foo -v, but that file was deleted or overwritten with a 
deifferent version, I would no longer be able to obtain that 
package-related information.

The other big problem is that there's no logical place to store metadata 
about the package as a whole. This includes essential metadata such as 
dependencies and conflicts, version information and a complete list of 
files installed by the package. Other less essential bit still very 
useful information is a description, the email address of the maintainer 
and so on.

If you don't already have that complete list of files installed by the 
package, then you have no way to determine what that list is in an 
efficient fashion and you need to know this when upgrading or removing a 
package. You would have to examine every file in the filesystem to know 
if it belongs to a particular package. This would make even minor 
upgrades take hours or days.

 > So I'm more in favour of managing configurations than managing
 > packages.

Hmm, I think you should have a look at the debconf stuff, then. When a 
debconfed package gets installed, it asks you pertinant configuration 
questions and automatically configures the package for you. It remembers 
your answers so you don't have to keep re-answering the same question 
whenever you upgrade the package. Isn't this what you are after?


Mike Gratton <jabber:mjg at> <>

LinuxSA WWW: IRC: #linuxsa on
To unsubscribe from the LinuxSA list:
  mail linuxsa-request at with "unsubscribe" as the subject

More information about the linuxsa mailing list