Hello again to all,
As I've said on a previous mail I'm already working on the cddtool and while
working on the parser for the cdd description and learning about current
tools (apt is great, but it is better when you look at all the options it
has ;) I've been thinking about my original proposal and have additional
ideas I would like to comment with people on the list.
The current proposal for the CDDTool:
http://wiki.debian.net/index.cgi?action=revisions&page_name=CDDTool&revision_id=4
talks about Task and Package paragraphs, but the idea is that each task is
one entity, so debconf preseeds and configuration scripts are used for all
the packages of the task.
On the proposal I said that the cddtool could be used to install, update and
remove packages, but there is no indication of how that could be integrated
with the usual Debian tools (that is, with apt).
After thinking about it I believe that we could support CDD updates using
apt and a common system for the cfg-scripts I talk about on the proposal.
The idea is to install hooks for apt with the cddtool. i.e. install the file
/etc/apt/apt.conf.d/10cddtool:
DPkg::Post-Invoke { "test -x /usr/sbin/cddtool && /usr/sbin/cddtool apt-pre-install-pkgs"; };
DPkg::Pre-Install-Pkgs { "/usr/sbin/cddtool apt-pre-install-pkgs"; };
DPkg::Tools::Options::/usr/bin/cddtool::Version "2";
The *Pre-Install-Pkgs* is called when the packages are already available but
before calling dpkg to unpack and configure them (the 'DPkg::Tools::Options'
is used to get a list of the actions that are going to be done on the
standard input of the cddtool invocation).
The *Post-Invoke* script is called after all packages are installed and
configured.
My idea is to use those scripts to *disable* non-policy compliant
customizations while installing or upgrading packages and reaply
customizations after installation. Note that this system's usage has to be
kept to a minimum, and that all files related to a customization that are
not going to conflict with the normal system should be handled using normal
debian packages.
Basically the system could be implemented using a library of scripts and
defining a policy:
1. If a configuration file can be customized using debconf, use preseeding
and avoid this system.
2. If a customization simply needs to change some variables of the original
config file, send a bug report asking the maintainer to add debconf support
for them.
On the meantime put the questions on your cdd-desciption package and handle
the configuration file yourself.
After all packages are installed, we copy the original file to a place we
can recover it from, like:
/etc/cdd/CDDNAME/orig_conffiles/orig_package/ORIGINAL_PATH
later we use a script (tha uses sed, cfengine or whatever we agree on)
against the original file to replace the needed variables and generate the
customized version.
The customized file is stored on:
/etc/cdd/CDDNAME/custom_conffiles/ORIGINAL_PATH
An later it is copied to it's original path and the customization is done.
To undo our changes we simply have to move all files on:
/etc/cdd/CDDNAME/orig_conffiles/orig_package/ORIGINAL_PATH
to their original locations before installing or upgrading packages.
We can do it for all the customizations or only for the afected packages
that are going to be installed or updated (preferred, as it is more
efficient).
Notes:
- The customized files have to be re-generated for each updated package or
for all packages after each cdd-description update or reconfiguration.
- The customized file is stored on two places to be able to detect if the
customization has been modified by the local administrator and let him
know that manual modifications have been done to the customized version.
To do it the files on '/etc/cdd/CDDNAME/custom_conffiles/ORIGINAL_PATH'
can be handled using 'utf' or a similar system.
3. If a customization needs a different configuration file as a base, do the
same as on option 2 with the original files and apply your scripts against
templates stored on:
/usr/share/cdd/CDDNAME/custom_templates/ORIGINAL_PATH
4. If the configuration needs something more complicated than a value
replacement, do the same as on options 2 and 3 with the original file and
generate the new configuration file using your own script.
Comments, Doubts, Suggestions?
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature