Re: push for policy change
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
Reply to: