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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
