Hi cobaco, one of the points wanted a specific package to be an "owner" for a given configuration file. Maybe this could be made unnecsessary.
"Only the admin is the owner of configuration files" might have been one of the ideas behind the current config file policy. With the outcome that config files should not be touched. One thing CDDs would like however is a safe way to manipulate those files. I have been trying to compose a wishlist for this thing not only from an CDD view. The CDD config issue might be solveable without a policy change, I am not even sure if a policy change would really help. Note the "configuration modifier" (for all desired options) and "modularisation" that the proposed changes would make required. The "configuration modifier" is the key here IMHO, and could also provide modularisation for non modularized configs. It's an issue needing/providing a configuration modifier modul. Well, here are the whishlist items for code rather than policy that I have gathered so far. For this particular CCD context especially the cascading defaults separately from the config files should be interesting: --- A future version of the configuration (modifier) system should idealy... - remove any need to manually copy customisations to new config files or to alternatively not get updated config files. - ease to (re)do/revisit config manipulation scripts with every new package (update). (Today maintainer scripts need to provide the complete funtionality from parser, validation, ..., logic. -> Incomplete sets of options and "managed by debconf" (don't touch or loose debconf functionality) sections are seen.) - provide sytem configs with cascading defaults: Defaults with different config levels: 0. software defaults (compiled in, not saved in config files) 1. system settings (explicity saved in /etc/*) compiled from different sets of defaults A. distro defaults (saved in some config system /usr/share/... dir) B. customized defaults (Custom Debian Distributions) (/usr/share/...) C. more customized defaults (Organisations etc.) (/var/share/...) ... and overridden by possible explicit (different) admin settings done in /etc (results in /etc/* to have an offset from the default resulting from A.B.C...) 2. settings for user groups (see debian package desktop-profiles) 3. user settings (explicity saved in ~/.*) - allow all levels to be networked by importing /usr/bin, some /usr/share/..., some /var/share/..., /etc and /home dirs repectively. - have separtated frontends and backends from the core - provide seamless adjustment of settings on every level for the frontends - provide central reference settings and linking (to keep track of and update multiple redundant occurances in various places upon changes (i.e. hostname, IPs etc.) - be able to provide possible options/values, comments and help. - separate config-system and config-system-configuration (fileformat/info about the software it configures. According to workflow of package maintainer, package-config-manipulator maintainer, config-system maintainer, customisation-maintainer, etc.) - not save config state outside of the configured software's original config storage. - understand the fileformat and not alter formating when applying changes. - have a modular config-system-configuration, so that it can be upgraded with files that can be part of the software packages of the distributions or from other sources. - have the possibility to draw-in necessary packages if the user wants to configure some not-installed functions. (interaction with package manager) --- Cheers, Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
