Control: tags -1 patch
*Sigh*
On Wed, 2020-06-10 at 08:38:05 -0700, Felix Lechner wrote:
> On Tue, Jun 9, 2020 at 11:15 PM Chris Lamb <la...@debian.org> wrote:
> >
> > Felix, can you help out? I am not in a position to contribute to this
> > discussion itself.
>
> Well, I wish I could. Guillem makes many alarmist statements,
This is a funny way to put it I guess. :)
> but fails to explain why the change is an undue burden.
I've done that multiple times now.
> I also do not know
> how to engage productively with visceral and absolute responses such
> as:
Obviously biased, but I don't see anything visceral in any of the
"selected" (out of context) quotes below. They reflect IMO either
astonishment or a reasoned view on the matter. If you disagree you
could have as well rebutted them, which you still have not done…
(Should really not be going over these, because this is yet again
another diversion from the matter at hand but…)
> > Err…
This was in reply to:
,---
As I explained on IRC this statement is probably untrue (and you did
not have the courtesy to mention that objection here).
`---
So pretty much astonishment at this, first because I'm not in the
habit of leaking conversations from IRC w/o permission, and second
because of the unsubstantiated truthiness claim veiled in as a
"possibility".
> > it does not make any sense whatsoever
> > does not match reality
> > it does not even make sense within a Debian-centric view
Supported in the context conveniently trimmed out.
> > I'll have to very much disagree
> > you have still not explained what this default change really accomplishes
> > besides inducing tons of work and breakage
> > No, they did not.
These are either substantiated opinion (also conveniently trimmed
out), or facts. If the facts are wrong, you can always challenge them.
> It's amazing how much time and energy Guillem expended on this issue
> here, on IRC, and in #962157 while dpkg has more open bugs than
> Lintian.
Wow, just wow, I'm not sure where to begin here TBH. First, I'm not
even sure how this is in the least relevant to this report, how it
is relevant to you how anyone else spends their time in a volunteer
project, and how that compares to anything else.
But this just feels like a pattern to me, when there are no more
technical arguments to make, you start either the unrelated diversion
and distraction, the personal comments, etc.
And, really, the bug reports have actually been 4 shortish emails. The
"bulk" of the time was on IRC, but that has not been the only and first
instance of endless and repetitive discussions going in circles, with
unrelated tangents all over the place…
> As you know from my past behavior with 'md5sums -z' or the odd
> contributor on Salsa, I am not opposed to compromise when it brings
> peace. In the present case, such a compromise could be a value 'none'
> to disable the default Guillem likes (and which I would like to
> remove).
Again with the personification, this is not something _I_ personally
like. I could personally adapt. This is something I do consider to
be a global bad default for the program and Debian, derivatives, etc
at large.
It's clear you want this behavior change, it's not clear why though.
The reasons I've seen from you are:
- it has been advertised.
- ftp-masters have requested it (and they are the only ones that
matter, at which moment I guess I wonder that's the point of any
non-fatal tags in lintian that ftp-masters do not use)
- a very vague and unsubstantiated "the current solution is simple,
elegant, straightforward and explicit".
- unrelated claims about the exit status being unreliable.
- other unrelated stuff from IRC.
The attached (untested, just «perl -cw» checked) patch, applied after
reverting commit 30ae7cab479e64bf58618e17854794112f8cc791 does not
really look complex to me TBH, in addition of fixing a small bug.
> At the same time, the change was widely released two weeks ago. Simon
> Quigley from Ubuntu announced it on debian-devel on May 25 [1], while
> I advertised the change repeatedly on IRC and added a note to DevNews.
> Some users may have already adapted their systems.
>
> [1] https://lists.debian.org/debian-devel/2020/05/msg00239.html
Yet again, advertising a change does not imply there's a justification
for it, that's not a technical nor even a good social reason. (Not to
mention that not everyone has apt-listchanges installed, so not even a
NEWS might be seen, and as mentioned the problem with that is that it
would go unnoticed given that it is a silent breaking change.)
> It would also give me more time to understand the possibly
> unreasonable burden on Lintian users across Debian and the derivative
> ecosystem. Simon may receive feedback from Ubuntu, a significant
> derivative. If there are real problems, I am happy to discuss a
> solution that reverts the default to Lintian's old setting.
This again shows that all the reasons exposed on IRC and on the reports
are not getting through, not being rebutted, and no actual rationale is
given. But with this style of communication, which requires endless
repetition, and uses polite language on the surface but with disrespectful
personal undertones, the only way I know how to productively interact
with, is not doing it. So I can only consider this indeed an unproductive
waste of my time.
Bye,
Guillem
diff --git i/commands/lintian.pm w/commands/lintian.pm
index 66c10b306..062a23651 100755
--- i/commands/lintian.pm
+++ w/commands/lintian.pm
@@ -167,7 +167,7 @@ Behavior options:
-E, --display-experimental display "X:" tags (normally suppressed)
--no-display-experimental suppress "X:" tags
--fail-on error,warning,info,pedantic,experimental,override
- define condition for exit status 2 (default: none)
+ define condition for exit status 2 (default: error)
-i, --info give detailed info about tags
-I, --display-info display "I:" tags (normally suppressed)
-L, --display-level display tags with the specified level
@@ -392,7 +392,7 @@ sub record_option_too_late {
sub cfg_fail_on {
my ($name, $value) = @_;
- @{$option{'fail-on'}} = split(/,/, $value)
+ parse_fail_on($value)
unless scalar @{$option{'fail-on'}};
return;
@@ -1007,6 +1007,27 @@ sub _find_changes {
exit 0;
}
+sub parse_fail_on {
+ my $value = shift;
+
+ @{$option{'fail-on'}} = split(/,/, $value));
+ my @unknown_fail_on
+ = grep {!/^(?:error|warning|info|pedantic|experimental|override|none)$/ }
+ @{$option{'fail-on'}};
+ die "Unrecognized fail-on argument: @unknown_fail_on\n"
+ if @unknown_fail_on;
+
+ if (any { $_ eq 'none' } @{$option{'fail-on'}}) {
+ if (@{$option{'fail-on'}} > 1) {
+ die "Cannot combine 'none' with other conditions: @{$option{'fail-on'}}\n";
+ } else {
+ @{$option{'fail-on'}} = [];
+ }
+ }
+
+ return;
+}
+
sub parse_options {
# init commandline parser
Getopt::Long::config('default', 'bundling',
@@ -1044,11 +1065,7 @@ sub parse_options {
if $option{'ftp-master-rejects'};
# check arguments to --fail-on
- @{$option{'fail-on'}} = split(/,/, join(COMMA, @{$option{'fail-on'}}));
- my @unknown_fail_on
- = grep {!/^(?:error|warning|info|pedantic|experimental|override)$/ }
- @{$option{'fail-on'}};
- die "Unrecognized fail-on argument: $_\n" for @unknown_fail_on;
+ parse_fail_on(join(COMMA, @{$option{'fail-on'}});
return;
}
diff --git i/man/lintian.pod.in w/man/lintian.pod.in
index fb97d305d..0fbc24e85 100644
--- i/man/lintian.pod.in
+++ w/man/lintian.pod.in
@@ -214,15 +214,14 @@ bug reports are always welcome (particularly if they include fixes).
These options overrides the B<display-experimental> variable in the
configuration file.
-=item B<--fail-on> {error | warning | info | pedantic | experimental | override}
+=item B<--fail-on> {error | warning | info | pedantic | experimental | override | none}
Causes B<lintian> to exit with a program status of 2 for the given
conditions. This option can be a comma-separated list, or it may be
specified multiple times.
-THERE IS NO DEFAULT, which is different from the way B<lintian> used
-to work. Also, 'warning' does not imply 'error'. Please specify both
-if you want both.
+The default is B<error>. Also, 'warning' does not imply 'error'.
+Please specify both if you want both.
=item B<-i>, B<--info>
