Hi all,
at the devcamp in Malaga last May [1] a lot of talk was done about ways
allow CDD's to configure debian packages as they need. One of the
conclusions reached was that modularized/multilevel config was the way to
go when possible.
In light of that, and the fact that lots of packages in Debian already
provide modularized configuration [2]. I think the bit in policy about
shared config files should be altered to reflect that modularizing the
configuration is the preferred option when possible.
So why am I sending this here instead of to the policy list? Well because:
a) I'd like some feedback/comments about wether my proposed wording is the
best we can do from a CDD stand point (I'm sure some improvements will be
suggested :)
b) more examples of modularized configuration in current practice wouldn't
hurt, and I'm sure there's lots I missed in [2]
c) I'd prefer to send this in as a request coming from the broader
CDD-community instead of from just me
The policy section under discussion is 10.7.4, quoting the relevant bit
below:
>>>>> begin policy quote
If it is desirable for two or more related packages to share a
configuration file _and_ for all of the related packages to be able to
modify that configuration file, then the following should be done:
1. One of the related packages (the "owning" package) will manage
the configuration file with maintainer scripts as described in
the previous section.
2. The owning package should also provide a program that the other
packages may use to modify the configuration file.
3. The related packages must use the provided program to make any
desired modifications to the configuration file. They should
either depend on the core package to guarantee that the
configuration modifier program is available or accept gracefully
that they cannot modify the configuration file if it is not.
(This is in addition to the fact that the configuration file may
not even be present in the latter scenario.)
>>>>> end policy quote
What I think is suboptimal in the above is that:
a) it doesn't talk about modularized config, only about a configuration
modifier program, which is not the preferred option
b) it kinda implies that only related packages should request this kind of
support from another package, and I'd like to see CDD configuration
packages included as well.
So here goes a first attempt at a better formulation:
>>>>> begin proposed replacement text
Sometimes two or more packgages need to be able to modify the same
configuration file. One such case is were related packages share a
configuration file (e.g. bash and other bourn compatible shells
share /etc/profile). A second case are configuration packages attempting to
configure a standard Debian system to better suit a specific purpose or
target-group. The specific purpose or target-group adressed by such a
package often allows more narrow configuration choices to be made that
wouldn't be suited as the default configuration of a package.
When more then one packages needs to be able to modify a configuration file
the following should be done:
1. One of the packages (the "owning" package) will manage the configuration
file with maintainer scripts as described in the previous section.
2. The owning package must provide a mechanism through wich the other
packages can modify the configuration.
The preferred way to do this is by modularizing the configuration
(both /etc/X11/Xsession.d and /etc/apache/conf.d are examples of such an
approach). The big benefit of modularization is that the origin of each
bit of configuration is clearly identified and delineated, which allows
each package to manage it's own configuration bits independendly. It also
removes the need to develop and maintain a configuration modifier program
When a modularized configuration is impossible a configuration modifier
program should be provided for the non-owning packages to use.
3. The packages that don't own the configuration file must use the provided
mechanism to affect any changes to the configuration. They should either
depend on the owning package to guarantee that the modify mechanism is
available, or accept gracefully when it isn't (in which case the
configuration file may not even be present).
>>>>> end proposed replacement text
[1] http://lists.debian.org/debian-custom/2005/05/msg00014.html
has Sergio's summary of the devcamp meeting
[2] some examples of packages currently providing a modularized
configuration setup are:
- apache -> /etc/apache/conf.d
- apt -> /etc/apt/conf.d
- cron -> /etc/cron.{d,hourly,daily,monthly}
- discover -> /etc/discover.conf.d & /etc/discover.d
- fish -> /etc/fish.d
- hotplug -> /etc/hotplug/blacklist.d & /etc/hotplug.d
- libpam -> /etc/pam.d
- logrotate -> /etc/logrotate.d
- sane -> /etc/sane.d
- sysv-rc -> /etc/rc[0-6S].d & /etc/init.d
- udev -> /etc/udev/rules.d
- x11-common -> /etc/X11/Xsession.d
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
Attachment:
pgpXCQTvw2Hvl.pgp
Description: PGP signature