Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Hi!
On Tue, 2022-06-14 at 01:26:02 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > So the problematic --fail-on default change never got actually reverted
> > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e
> > omitted the relevant part that would make it work. :(
>
> Can you please elaborate what exactly is the bug? You refer to
> something being problematic without explaining what actually is
> problematic.
>
> You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and
> https://bugs.debian.org/962158 which has been closed about 2 years and
> ca. 35 Lintian releases ago. That thread in #962158 is quite long and
> difficult to grasp.
lintian used to exit with a non-zero value when it emitted at least
one error tag. This was changed, for some reason, and then it stopped
doing that, instead requiring users to specify --fail-on=error. This
was supposedly reverted, but the patch that got applied that fixed
this at the time of submission did not apply at the time it got
committed due to refactoring, and it was ineffective. As such the
--help output now is misleading, mentioning that the default --fail-on
is "error" when it is not.
The above caused the below problems. ↓
> > None of the previous arguments against the default change brought up
> > in #962158 have stopped being relevant (also contrary to the commit
> > message…). Worse, this sneaked in what has shipped now in a stable
> > Debian release. :( So any errors found in CI systems and through other
> > tooling has been silently ignored since then. :/
>
> This doesn't really makes the issue easier to understand. I don't ask
> for a patch, but at least for a list of defects what is wrong where
> and probably why.
>
> So far I got that there is an issue with the exit codes having changed
> to be somewhat less helpful for automatic usage. (When did it change
> and how? Do you happen to know a commit id? What condition should in
> your opinion cause which exit code?)
I'd have to re-dig all this. I might just try to provide a patch, I
think should probably be a one-liner.
> > Only noticed now due to #994414, a great excuse to now keep the broken
> > behavior I guess.
>
> So this bug report actually should no more be fixed?!?
The point of that comment, was that because Felix was pushing for that
behavior change even when no apparent good reasons were given, and
then after the behavior was supposedly reverted (but in fact it was
not), when that bug report about the man page also mismatching the
current behavior was filed, instead of properly fixing the behavior,
he used the opportunity to keep pushing for the IMO broken behavior.
> > (Where the --help output still does not match…)
>
> So --help seems outdated. At which line or option exactly and what
> should it say instead?
IMO it should stay as it is and the behavior reverted. But if you also
disagree, then it should reflect reality.
Thanks,
Guillem
Reply to: