Bug#1115177: lintian: warns about latest host (dev) tools API available in stable
On 17/09/25 2:34 am, Thorsten Glaser wrote:
> On Tue, 16 Sep 2025, Nilesh Patra wrote:
>
>>>> But why should it be omitted? I think moving it to info should be good
>>>> enough to do here -- we would like to encourage maintainers to move to
>>>> a newer watch version eventually.
>>>
>>> It’s likely fatal if they upgrade prematurely, though.
>>
>> I don't understand this part. Can you be verbose about how this
>> appears fatal to you?
>>
>> Lintian version released to unstable is not meant for trixie and are
>
> Yes, but the watch file especially is expected to be consumable
> by developers and other tooling on trixie. Heck, probably even
> bookworm at least. There’s a service for this even, what does the
> backend behind qa.debian.org/cgi-bin/watch use?
I don't see how adding d/watch v5 tag in lintian release for
unstable affects any of that.
The d/watch in trixie is v4. The lintian version in trixie has
checks for d/watch v4. It considers d/watch v4 as the latest
watch version.
Packages with d/watch v5 will not enter stable. At best, they can
be in stable-bpo. And none of it has any functional impact here.
>>> (And, perhaps I was a bit angry, but recent lintian churn has
>>> been immense every time it got updated… this is getting on the
>>> nerves of all package maintainers…)
>>
>> I'd like to hear reasons of what led you to say this, and what specific
>> pain points you have had since past few (with past one year) lintian releases.
>
> It’s been a buildup. Lots of tag renamings (some tags got renamed
> twice even), the whole move to the new format with the square
> brackets (which made the lintian from the previous stable even
> segfaulting), and then a whole flood of rather opinionated new
> tags that even partially are wrong (e.g. the one that complains
> about debian/* not having the current year listed in copyright
> even when there was nothing passing threshold of originality in
> the current year).
All those changes were added back in 2021 and 2022. I actually did
the effort to fact check this in `git log`. This means that there
was nothing "getting-on-nerves" that has happened in the past year
or two.
Anyway, I think there's no further action for me to take here. I
will stop engaging in this bug report further as the discussion here
is mostly done IMO.
Reply to: