managing configurations, not packages
mike at vee.net
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
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
> 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
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
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 jabber.vee.net> <http://web.vee.net/>
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.openprojects.net
To unsubscribe from the LinuxSA list:
mail linuxsa-request at linuxsa.org.au with "unsubscribe" as the subject
More information about the linuxsa