Hello Adrian,

Thank you for your continued effort to get this bug resolved.

On Sat, Mar 10 2018, Adrian Bunk wrote:

>> Please expand on why you think this is the way we have to proceed.
> you skipped the part of my email with the explanation:
>   with such a piecemeal approach
>   we risk fragmentation based on debhelper compat level used, with every
>   new compat level installing different files in different locations.

This is not inevitable.  What I am envisaging is:

- we hash out our preferred solution either in this bug or in the
  debhelper bug, with the debhelper maintainer having the final say on
  what gets implemented
- debhelper implements all of that solution at exactly one compat level
- the archive starts to use that compat level
- Policy is updated.

This is the standard way to make changes to Policy.  The alternative is
releases of Policy rendering many packages buggy, and that is undesirable.

I don't think you've explained why you think that can't happen for this
bug too.  You're right to note the piecemeal compat level risk, but now
that we're aware of that risk, it seems straightforward to mitigate.
We just avoid implementing anything in debhelper until we can implement
it all in debhelper.

> Your point of view sounds to me like
>   In 15 years policy will be changed to document whatever the
>   debhelper maintainer decides to implement in dh compat 12.
> To me this doesn't make sense.
> This bug is now over 10 years old, and at some point someone has to
> decide which files should be installed and where.
> The obvious way forward would be to try to find a consensus here,
> and then ask on debian-devel whether there are any objections.
> If anything ends up being controverial and a decision is required, our
> constitution already makes it clear who is responsible for the decision
> (and this is not the debhelper maintainer).

Our delegation gives the Policy Editors editorial authority over the
contents of the Policy Manual, but by means of the Policy Changes
Process we delegate that authority back to the body of DDs.

That means that changes have to establish consensus.  How do we
establish consensus on an issue like this, just by talking about it
where everyone has a view?  That's extremely hard.  There's no way to
bring the discussion to a close, and so the bug is still open after 10

What we can do in this case is shortcircuit that process of establishing
consensus by means of debhelper.  The debhelper maintainer has authority
over what debhelper will implement.  So he implements something.  If
it's basically a sensible convention, almost everyone will start using
it, even if it is not their number one choice of solution.  But then we
have enough of a consensus, so it's no longer problematic to change

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to