El Thu, Jan 19, 2006 at 12:57:23AM +0000, Jose Manuel dos Santos Calhariz va escriure: > Hi, Hi, > Now I am working in a solution with small scripts and patchs files, > and using dpatch. I know dpatch is to apply patches into upstream > sources, but I have made it work, using "--workdir /", and a fake > debian dir inside "/etc/package". The scripts will be executed by the > admin and not by postint during installation, so violating one less > rule of the Debian Policy :) > > I hope in the next days to present a working example. For now I would > like to ask to the list: > > - Have anyone used patchs to change configuration files? Used > something better than dpatch to manage them? I've used systems like changetrack to keep manual configuration file changes on a revision control system, but not to configure systems; IMHO patches are not well suited for customizing configurations, there are a lot of things that can break if the configuration is edited by hand or using package scripts that handle the debconf answers. > - Have anyone other ideas, pro or cons, about my approach to the > problem? I did an specification of how to handle configuration files using an special kind of diversions; the idea is to remove customizations before package installations, upgrades or removals and apply them again after installations or updates. The specification is included on the cddtk docs: http://people.debian.org/~sto/cddtk/cddtk-apt.html but I have not worked on the tool for a while. Anyway, I've been working on a configuration system for our CDD that uses some of the techniques I was thinking about, once I have it finished I'll move the interesting bits to the cddtk (the system is is already working, but I have to build a full set of configurations for different services). The current system is implemented using shell scripts and the basic idea is to provide a set of templates for each set of configuration files. Each template includes variables that are replaced when installing the configuration file. If you want to take a look the support system is available on: https://lliurex.net/svn/lliurex-pool/cdd/trunk/llxcfg-runtime/ And there are work in progress customizations in: https://lliurex.net/svn/lliurex-pool/cdd/trunk/llxsmbldap-common/ https://lliurex.net/svn/lliurex-pool/cdd/trunk/llxsmbldap-server/ Currently they are enabled calling some scripts by hand and the customizations are not enabled and disabled on package updates, but things will be more automated soon. The aproach I'm using is to try to leave the debian package conffiles alone if possible and generate the custom configuration files in non conflicting places, that way the conffiles are owned by the customizing package and usually the configuration can be done in a way that enhaces the support for user customizations without breaking the configurations. Of course, if a program or package can't use different configuration files I go back to the diversions system, but the number of diverted files can usually be kept low. A good example is the customization of the SAMBA or LDAP servers; my current system provides a customized init.d script for each server that executes the service using different configuration files (the custom config for SAMBA is generated in /etc/CDDNAME/samba and for LDAP in /etc/CDDNAME/ldap) and different /var dirs (the server PIDs are stored on /var/run/CDDNAME and things like the LDAP database is generated in /var/lib/CDDNAME/ldap instead of /var/lib/ldap). When the user wants to enable the customized version of the service he or she executes an 'enable' script that installs the custom /etc/init.d/ scripts, creates the configuration files form the templates and optionally disables the default init.d script for the service. The scripts used to generate the customized conffiles can be written using cfengine, replacing variables with my shell scripts or using whatever system the developer wants; the idea is that with the current infrastructure the user does not need to touch the customized files and if he or she does it the customization scripts can decide how to handle modified files (in my current system I overwrite the files because I'm giving a clean way of overriding the customized configuration files using includes, but if a service does not allow me to do that maybe those files will be treated differently). In any case, I don't plan to use patches to handle customizations, maybe I'll try to support upgrades for modified conffiles using diffs, but I'm sure that unless the changes are minimal the best option when things don't work automatically will probably be the same used by dpkg... that is, tell the user about the changes and ask about keeping the current version or replacing it. Greetings, Sergio. -- 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