[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Draft proposal for handling configuration file manipulations in Debian blends

Hi all,

after having worked with the Debian Edu team for a couple of months now I would like to make a proposal on how to address configuration file manipulation within Debian blends.

For further reading on configuration file manipulation and Debian policy violation refer to bug #311188 in BTS:

To address #311188 the latest approach that has been discussed is enrolling the maintainers of all affected packages (and that can be many) to add blend-customized debconf values to their packages so that a clean preseeding of the package is possible.

Only a short time ago Marius has asked for debathena as a means to legalize what blend packages like debian-edu-config are doing to config files of other packages.

I agree with Jonas that debathena also fiddles with other packages' config files and that this causes the same violation of the same Debian policy 10.7.4 as described in #311188.

So, my opinion is that without implementing the blending mechanism within Debian policy itself (and that is also: within dpkg itself), we may possibly stall here for longer.

So, my proposal is:

 * let Debian blends become a real element of the Debian package system

 * that is: implement in dpkg three options:
   - Option 1: --blend=<blend-name>
   - Option 2: --unblend
   - Option 3: --init-blend (or --native2blend or similar)

 * in FHS we provide/define blend namespaces in /etc
   - e.g. /etc/blend/edu
   - or /etc/blend/gis
   - ...

 * blend packages with configuration files (like debian-edu-config) will put
   their blended config files into /etc/blend/edu/<etc-like-tree>

So on installation of a blend config package the following might happen. I will use the example of debian-edu-config (d-e-c) from here on...

 * every package that gets manipulated by d-e-c has to be in Pre-Depends of
   d-e-c. (I am aware of DDs not liking this and trying to avoid that
   whereever possible, maybe we find another approach here)
 * d-e-c installs its files targeted for /etc/* into /etc/blend/edu/*
 * on postinst every native Debian package that is affected by the d-e-c
   configuration override gets prepared/tagged by a
   - dpkg --blend=edu <package-name>
 * This blending process may do the following...
     **of course, the below has to become a legal part of Debian now...**
   - create copies of existing configuration file(s) <conf>.d folders in

     /etc/<folder>/<cf-file> -> /etc/<folder>/<cf-file>.dpkg-native
     /etc/<folder>/<cf-folder>.d -> /etc/<folder>/<cf-folder>.d.dpkg-native

   - divert the original configuration file and <conf>.d folder names to the
     corresponding files/folders in the /etc/blend/edu namespace.
   - tag the affected package (maybe in /var/lib/dpkg/info) as blended
* Alternatively, if the configuration files of a package shall not be replaced
   by d-e-c then we also find a dpkg --init-blend <package-name> command call
   useful (or --native2blend or --clone-native2blend or ...).
   -> install a copy of the original package's config files from
   /etc/<config-folder> -> /etc/blend/edu/<config-folder>
   After this, configuration files provided by the package maintainer can be
manipulated with cfengine (within /etc/blend/edu/<config-folder>, of course.
 * On package upgrades the dpkg system has to recognize if a package is
   in blend state or not. If it is in blend state, the dpkg system has to
   install new configuration files with .dpkg-native file suffix.
* With such a mechanism the system can also easily be unblended (reverted to a
   vanilla/native Debian installation). -> dpkg --unblend <package-name>

Happy for feedback,


mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de


Attachment: pgpmMTBuqZHde.pgp
Description: Digitale PGP-Unterschrift

Reply to: