On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> 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 ensures that policy will always be horribly outdated.
> This is the standard way to make changes to Policy. The alternative is
> releases of Policy rendering many packages buggy, and that is undesirable.
A new debhelper compat level making packages buggy according to policy
is what is desirable?
> 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
Let me repeat what I already wrote earlier in this bug:
IMHO the way forward is to find a consensus text for a policy change,
Cc debian-devel on the proposal, and if no objections are raised release
a new policy with these changes.
> 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
The Policy Editors are a delegation, and the debhelper maintainer is
just a random person who happens to maintain this specific package.
Precedent is also that the Policy Editors do use their powers to
push through even a change that makes thousands of packages buggy
after an objection has been raised:
I begin to wonder whether I should take this personally.
> Sean Whitton
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed