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:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188To 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.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188#294I 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
<package-name>
/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 bemanipulated 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 -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpYUxdkjkRxo.pgp
Description: Digitale PGP-Unterschrift
