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>
pgpQ4CkwJm9nK.pgp
Description: PGP signature
