Bug#962158: lintian: New very problematic --fail-on default value
On Thu, 2020-06-04 at 15:58:47 -0700, Felix Lechner wrote:
> > This change means that any current caller which uses lintian as part
> > of its acceptance testing will now silently let broken things through
>
> As I explained on IRC this statement is probably untrue (and you did
> not have the courtesy to mention that objection here).
Err…
> From what I can
> tell, the FTP Master (who are arguably the one "acceptance tester" who
> really matters) parses the tags. [1] Please let me know if you know
> otherwise.
As mentioned already on IRC and in the original report, at least all
the tools I listed are affected, including any local setup, in-house
CI deployments, CI integration in source forges (local and public,
including salsa), etc.
And also as mentioned on IRC, it does not make any sense whatsoever to
set such a default for a single user who can just change their code
base once, instead of forcing the entire ecosystem, within Debian,
its derivatives, and local and private setups to adapt to this change.
Considering ftp-masters the only acceptance tester that really matters
is a very Debian-centric view that does not match reality. Not to mention
that it does not even make sense within a Debian-centric view, as now
maintainers uploading to Debian, which rely on lintian to check for
brokenness that ftp-masters does not consider fatal, will start uploading
such broken packages into the archive…
> > If the default change made sense due to some technical rationale, this
> > effort might be worthwhile
>
> As I likewise explained on IRC, Lintian's return status was
> unreliable. Some program errors exited with status 1 and others with
> status 2, while detecting error tags always produced status 1. Lintian
> was also unable to use Perl's 'die'. The proper remedy was to always
> use status 1 for program errors. That step alone would require any
> automated user to examine their scripts.
And as mentioned on IRC, this also has little to do with the default
change. When you run lintian and it fails for any reason, be it
internal or from linting issues, people in general really want to fail
the acceptance test, so that if it is an internal error it can be
analyzed, reported, or worked around. In the same way people do not
ignore gcc ICE (internal compiler errors) in contrast to syntax errors.
So there's really no reason at all in general to be changing callers
to special case lintian failing internally.
> The 'fail-on' command-line option resolved a long standing problem
> with the implicit behavior your so cherish (#709932).
Also as mentioned on IRC adding this option has nothing whatsoever to
do nor it requires changing the default.
> Instead of
> adding more complex options, the current solution is simple, elegant,
> straighforward and explicit.
If with the current solution you mean the default change, then I'll
have to very much disagree. That change is just wrong. And you have
still not explained what this default change really accomplishes,
besides inducing tons of work and breakage, and letting a single
caller (DAK) avoid having to add the new option.
> And again, automated users already had to
> look at their scripts. It was the perfect timing to make both changes.
No, they did not.
Thanks,
Guillem
Reply to: