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 is the standard way to make changes to Policy. The alternative is > releases of Policy rendering many packages buggy, and that is undesirable.
The standard way is to have a transition period where policy allows for both behaviour. This way, debhelper can be updated without breaking policy and developers would have a reference for the new behaviour. Then the old behaviour is deprecated. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.