Re: push for policy change (config manipulator/modularisation)
Hi cobaco and all the others,
please note that all any policy can do is push responsibility away (to
maintainers). The real job has still to be done anyway.
Lets figure out a smart way to do the real job.
Am Samstag, 7. Januar 2006 11:45 schrieb cobaco (aka Bart Cornelis):
>
> I agree that any configuration manager preferably would provide
> modularization somehow, however such a beast is not in widespread use,
> which means there's no way we're gonna get that into policy at the moment.
Correct, and a policy change is not what I wanted to propose.
Openly pushing some configuration manager is of course not better than doing
so implicitly by pushing policy for config manipulation functionality.
In the proposed policy change the maintainer scipts asked for are the beasts.
Each complying maintainer will have to provide and maintain their own beast.
Instead of policy pushing I'd see the job of CDDs to work on solutions
together with other maintainers.
Look at debconf, it is there. Some improvements to debconf or a helper library
could greatly ease maintainer script writing/maintainig.
Using the helper library should be easier than doing all by hand in the
maintainer scripts.
With such a library a policy change would be obsolete. A policy change without
such a library would still require the library or be quite suboptimal.
> every file that isn't created by the admin must have an 'owning' package
> IMO,
Yes, that is basicly the understanding now.
Seen from another angle though the package wich is configured by the file may
only provide a mechanism to create it for the onwer.
In this way of looking at it config file creation can of course also be
offered by other (modular) packages. And debconf is just one of those
packages.
> this is not a problem in any case, unless you have an owner that's
> effectively going 'hands of everyone', thus prohibiting configuration
> packages from automating those configuration changes in a policy-compliant
> manner.
I'd see any "managed by debconf (database)" file or section as a "hands off
your own config file, admin!" thing. Here debconf must be the owner in order
to ease automating, because we lack tools that could upgrade a file the admin
has modified by hand or other tools. If he insists/has to do it he will be
cut off the upgrade path.
> Well having modularization/multilevel config recommended in policy would
> help in the following ways IMO:
> - it would encourage maintainers to look at the issue, and establish it as
> recommended practice
Leaving to solve "it" (by maintainer script config tools) to the maintainers.
> - it would also raise any request for such from wishlist to minor,
> normal, or important (as it's a should directive). This will make it less
> likely for maintainers to just dismiss the request out of hand.
increases pressure (and resistance)
> > Note the "configuration modifier" (for all desired options) and
> > "modularisation" that the proposed changes would make required.
>
> recommended not required, note the 'should be done' instead of 'must be
> done'
Well, in the logic of politics, any policy that does not increase pressure
would be useless.
And quoting from the original message:
2. The owning package must provide a mechanism through wich the other
packages can modify the configuration.
---
The thing I'd like to point out for readers here is that much energy can be
lost running in the wrong direction. It will only drag on the
persons/organizations involved. Only providing the better alternatives will
really improve the situation. Don't get to believe in centralizing decision
making.
Distros, CDDs, admins, users, the whole free software community benefits and
awaits a config system solution. Whereever the seed will come from.
The question is what criterias will make a seed successful, thus I started the
list posted.
Regards,
Christian
Reply to: