On Saturday 07 January 2006 15:15, C. Gatzemeier wrote:
> Am Samstag, 7. Januar 2006 11:45 schrieb cobaco (aka Bart Cornelis):
> please note that all any policy can do is push responsibility away (to
> maintainers). The real job has still to be done anyway.
the reason to push for a policy change is not to push responsibility to
maintainers. The reason is to make maintainers aware of the issue. Which
makes it more likely that patches we send in will be accepted, or accepted
withoutfirst having to debate/explain the need for it in detail to each
maintainer individually. (if the maintainer now beats us to it that's
great, but it's not the point)
> 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.
debconf is a great example of how a policy change can help actually:
there were several maintainers that didn't bother using debconf (even though
patches where provided) untill it was documented in policy (which also made
NMU's to get there possible).
> > 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.
Note that debconf handling done right would parse the config-file and allow
the admin to change whatever he wants. The fact that we do end up with
debconf only sections or files in practice points to lack of good tools.
Which is definately a problem we should work on.
However from a CDD-standpoint even limited debconf-handling is better than
nothing, as without even that we're left with only cfengine-scripts. Whose
invocation we can't automate while complying with policy.
> > recommended not required, note the 'should be done' instead of 'must be
> > done'
>
> And quoting from the original message:
>
> 2. The owning package must provide a mechanism through wich the other
> packages can modify the configuration.
right, that 'must' should be a 'should' also
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
Attachment:
pgpZJDhnehREo.pgp
Description: PGP signature