Bug#709003: lintian: Evaluation of current experimental tags

[Niels Thykier]

Package: lintian
Version: 2.5.12
Severity: normal
Control: block -1 by 699059

Started at [1], but seeing as I haven't had time to deal with it yet I
fear it might "disappear" in the depths of my mailbox.

I have tried to summarize the current state from the debate on the
list, which I believe to be:

P python(3)-depends-but-no-python(3)-helper
u package-contains-no-arch-dependent-files
- has false-positives on "pkg [linux-any]" dependencies.
d package-contains-broken-symlink
- Suggested that we keep it until #699059 is fixed.
u duplicate-files
- suggested pedantic/wild-guess (NB: partly done, I think)
- avoid triggering on doxygen stuff (or small files in usr/share/doc)
u embedded-pear-module
- need talk with php/pear maintainers to confirm/improve accuracy
and expanding the detection list.
? shlib-calls-exit
- There was some disagreement here, but it seems to have ended in favor
of keeping the tag. Possibly with whitelisting some known cases, e.g.
Apache modules?

Legend:
p, P -> "Promote(d) to non-experimental as-is"
d, D -> "Drop(ped) the tag"
u, U -> "Update(d) the tag and then promote/re-evaluate"
? -> "Needs more info"

(Upper case means it has already been done. i.e. P is "already
promoted", where as p is "intend to promote as-is").

~Niels

[1] https://lists.debian.org/debian-lint-maint/2013/04/msg00051.html


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Russ Allbery]

Niels Thykier <ni...@thykier.net> writes:

> ? shlib-calls-exit
> - There was some disagreement here, but it seems to have ended in favor
> of keeping the tag. Possibly with whitelisting some known cases, e.g.
> Apache modules?

I further investigated the Apache issue, and I see no sign of any other
facility provided to handle a missing but required configuration
directive, which was the specific case that I ran into. There are
mechanisms to handle a syntax error in a directive that is provided, but
once the configuration has been parsed, the after-config hook has no way
of returning a fatal error to Apache.

That said, this is an edge case that other Apache modules appear to
address by just not having any required Apache directives (instead, the
module is just deactivated with loud warnings if the directives aren't
present). I will take that approach upstream when I get a chance; in the
meantime, I can just override this tag for Apache modules.

That does leave the problem that libtool convenience libraries that are
used for both command-line programs (where fatal error reporting is
desirable) and shared libraries (where it isn't, but the shared library
never calls the relevant function) will trigger false positives for this
tag. This affects basically every shared library for which I'm upstream,
so it's kind of annoying.

The ideal, of course, would be for the linker to be smart enough to strip
the unused entry point from the convenience library when it is merged with
the shared library, but it alas isn't smart enough to do that even if the
fatal error entry point is isolated to its own *.o file that is completely
unused by the shared library.

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