Package: debian-policy
Version: 3.6.2.2
Severity: wishlist
Tags: patch
Hi all,
looking at section 10.7.4. from the viewpoint of CDD's we'd like to propose
some small changes to it:
- the first part of the change is to explicitly mention configuration
packages as used by CDD's as a reason to consider sharing configuration
files, while explaining the rationale for these kinds of packages.
- the second part of the change is to document one of the conclusions
reached at the cdd-devcamp in Malaga last May[1], which is that the
already widely used[2] approach of modularizing the configuration is the
preferred way to go about shared configuration when possible.
patch with the proposed wording is attached.
[1] http://lists.debian.org/debian-custom/2005/05/msg00014.html
has Sergio's summary of the devcamp meeting
[2] there's lots of packages that modularize their configuration with a
<something>.d directory, where packages or admins can drop configuration
snippets, some examples of this approach on my system include:
- 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
the common desktop environments (kde, gnome, xfce, and freedesktop)
approach modularized configuration in a slightly different way, allowing
multiple configuration sets to be stacked (the desktop-profiles package
provides a way for controlling that stacking)
--
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)
--- debian-policy-3.6.2.2/policy.sgml 2005-12-24 22:41:09.000000000 +0100 +++ patched/policy.sgml 2006-01-12 09:05:04.000000000 +0100 @@ -6961,31 +6961,57 @@ </p> <p> - If it is desirable for two or more related packages to - share a configuration file <em>and</em> for all of the - related packages to be able to modify that configuration - file, then the following should be done: + 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. + <p> + + <p> + When more then one packages needs to be able to modify a + configuration file the following should be done: <enumlist compact="compact"> <item> - One of the related packages (the "owning" package) - will manage the configuration file with maintainer - scripts as described in the previous section. - </item> - <item> - The owning package should also provide a program - that the other packages may use to modify the - configuration file. - </item> - <item> - 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.) + One of the packages (the "owning" package) will manage + the configuration file with maintainer scripts as + described in the previous section. + </item> + <item> + <p> + The owning package should provide a mechanism through + which the other packages can modify the configuration. + </p> + + <p> + 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. + </p> + + <p> + When a modularized configuration is impossible a + configuration modifier program should be provided for + the non-owning packages to use. + </p> + </item> + <item> + 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). </item> </enumlist> </p>
Attachment:
pgpRhPWW7xCHF.pgp
Description: PGP signature