On debhelper compat levels (Was: Re: Why do we list individual copyright holders?)
Jonas Smedegaard:
> Quoting Niels Thykier (2018-01-02 09:23:00)
>> Andrey Rahmatullin:
>>> On Mon, Jan 01, 2018 at 08:40:38PM +0100, Jérémy Lal wrote:
>>>> wouldn't it be simpler to couple debhelper dependency to
>>>> Standards-Version ?
>>> There are packages which may break with newer debhelper, but can be
>>> easily updated to the current policy.
>>>
>>
>> Also, there are packages that deliberately hold back on adopting new
>> debhelper compat levels because they want to be backportable as-is to
>> stable (even up to oldoldstable in some cases).
>>
>> That said, I do agree that a maintainer should have to care about
>> fewer turning wheels in debian/control than what our current packaging
>> design requires us to do.
>
> Maybe extend debhelper to support compat file content of "latest". Or
> simply treat a missing compat file as implicitly meaning "latest".
>
>
> - Jonas
>
I have considered it, but it will effectively lead to a situation where
I cannot ever make a new compat level.
The point of compat levels is to change behaviour in an incompatible
way. Because it is opt-in, a new compat level breaks 0 packages (except
a handful of early adopters). Whereas if I implement a named "latest"
compat level, then I possibly break every single package with that named
compat level.
As more and more adopt it, the compat bump will break more and more
packages leading to a situation where it is nearly impossible for me to
implement an actual compat bump.
(This would have been less problematic if we could determine exactly
which packages are affected and how they are affected, so we could do
MBF before the bump. However, that it is impractical for many changes.)
Thanks,
~Niels
PS: For the curious, this is also why I retracted the named
"beta-tester" compat level that existed in most of debhelper 10 just
before announcing the compat 11 beta.
Reply to: