> > it would only be possible to use debconf values in violation of 10.7.4
> > if the package is in violation by using debconf values to improperly
> > edit "conffiles", as 10.7.4 has nothing to do with debconf values.
> >
> > if the package properly uses debconf values (only on "configuration
^^^^^^^^^^^^^^^^^^^^^^
> > files" not marked as "conffiles", with provided tools to edit the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > "configuration files"), it would be compliant with 10.7.4, as i read
^^^^^^^^^^^^^^^^^^^^^^
> > it..
>
> Then read again. First two paragraphs of 10.7.4 relates to conffiles
> only, but the rest is generally about configuration files.
read my above paragraph again... i wasn't saying that debian-edu-*
packages weren't, in some way breaking policy, i was saying that your
suggested (and snipped) third approach did not account for the above
highlighted policy-compliant approach to use debconf values.
> >>I agree that for a future Debian we should seek more flexible
> >>configfile handling, but for current Debian that is not an option
> >>(because changing the world takes time so *is* future).
> >
> >
> > some of us need to work with the current stable debian release to
> > maintain sanity, and some imperfect workarounds are necessary until the
> > issue can be resolved, no?
>
> Yes.
>
>
> > i don't see the point of dragging this out without proposals about how
> > to fix it, as the workarounds are at least a temporary necessity.
>
> I am not sure what is your point here.
you seem to be saying "this is broken, we need it fixed."
and others seem to say "yes, we know, but we have other priorities right
now."
without *providing* and alternative, re-stating the issue will not solve
it.
> I want a long term solution to this. But I suspect it takes time, as I
> suspect the long term solution requires a lot of maintainers agreeing to
> enhance their packages to be "remote-controlled", and possibly some
> policy rules needs to be thought out about when it is acceptable to
> (ab)use those remote-controls through maintainer scripts of other
> packages (directly or indirectly as is the case in bug#31188).
> So I want to work on shorter term fix as well, in case Debian Etch is
> released before the world had changed drastically enough for our chosen
> approach to no longer be release-critical.
> Besides, if we are smart, our temporary hack is designed to help ease
> the long term solution! With this I mean reusable hacks[1] instead of
> isolated complex workarounds.
i await your fine code to do all this :P
live well,
vagrant
Attachment:
signature.asc
Description: Digital signature