[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of current experimental tags



Jakub Wilk <jwilk@debian.org> writes:
> * Niels Thykier <niels@thykier.net>, 2013-04-07, 17:33:

>>* python(3)-depends-but-no-python(3)-helper 2.5.4 (Nov 2011)
>>  - In total, some 40-46 cases
>>  - both tags are "serious/possible" (E)
>>  - I am considering to promote to "non-experimental".

> I was going to propose to un-experimental this one, too. Unfortunately, a
> few of these tags are false positive. This is because people do crazy
> things like this:

> WITH_PYTHON2 = $(shell test -f /usr/bin/dh_python2 && echo "--with python2")
> %:
> 	dh $@ ${WITH_PYTHON2}

> Lintian has of course no way of knowing with will WITH_PYTHON2 expand
> to... But perhaps in these crazy cases people should just add
> overrides. (FTR, this is tracked as #659335.)

We could also just assume that anyone using shell substitution variables
in the dh line of debian/rules know what they're doing.  Lintian makes
similar assumptions elsewhere in rules handling.

>>* duplicate-files
>>  - Some 35k tags in < 1000 packages
>>  - a lot of that is caused by doxygen (etc.)
>>  - will possibly be preceived as a lot of busy work by maintainers

> The tag helped me to greatly reduce a binary package size once, but most
> of the time my reaction to it is "meh, I don't care".

We could make almost all of the Doxygen noise go away by just ignoring
small files in /usr/share/doc.  (The Doxygen noise is indeed really
annoying.)  I kind of like the tag otherwise, but it's definitely
pedantic, not minor, and is probably pedantic/wild-guess.

>> * shlib-calls-exit
>>  - Some 2300 tags in < 1000 packages
>>  - Russ suggested that this tag should be dropped[2].
>>  - it is wishlist/possible (I)

> It's been almost always true positive for me, so I'd prefer if we kept
> it.

Are you certain?  (In other words, how have you confirmed that the library
actually calls the code that calls exit?)  It gives false positives on
every shared library package for which I'm upstream because I use shared
code for error handling and the linker isn't smart enough to drop the exit
calls that are unreachable.  If you only checked by looking to see if exit
was in the code that's linked into the shared library, it of course is,
but it's not possible for the shared library to call that code.

It also gives false positives on any Apache module that reports fatal
syntax errors in configuration files, since the accepted way of doing that
is to call exit.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: