Bug#506673: lintian: shlib-missing-in-control-file and symbols-declared-but-not-shlib wrong for libraries without versions
Raphael Hertzog <hertzog@debian.org> writes:
> On libc6 in experimental I see:
> E: libc6: shlib-missing-in-control-file libpcprofile.so for lib/libpcprofile.so
> E: libc6: symbols-declared-but-not-shlib libpcprofile.so
>
> But since libpcprofile.so has no version in its soname it simply isn't
> representable in the shlib system… so it shouldn't be an error.
I looked at this in some detail today. This particular situation
(libraries with no meaningful version information) are the majority of
those tags issued across the archive, and I agree that they're not the
right tags since those files can't be represented in the shlibs system at
all.
It does look like they can be represented in the symbols system because
the symbols system doesn't have the separate version field and instead
shows the complete SONAME. Is that correct?
Incidentally, we currently have no complete documentation about how the
version field in shlibs actually works, so far as I can tell. All the
documentation we do have says that the version listed in shlibs is the
part after .so. in the SONAME, but library SONAMEs of the form
libfoo-<version>.so apparently also work fine. It's not intuitively
obvious, once you've realized that, that other things couldn't also work,
so it would be nice to have a more accurate description of exactly what is
happening somewhere. I've seen several different regexes used to try to
extract versions from libfoo-<version>.so library names and they all
disagree subtly.
What I'm committing for the next release is a patch that will look in
public library directories (ones searched by ldconfig), warn about those
shared libraries with SONAMEs that contain no version information, and
then exclude them from shlibs checks. I'm using the most generous regex
for matching libfoo-<version>.so style SONAMEs, so basically anything with
a hyphen in it will pass, which means we'll still issue the wrong tag for
a lot of misplaced plugins and private libraries. Libraries without
version information in the SONAME will get a tag saying that private
libraries should be moved to a subdirectory and special cases (such as the
glibc ones) should get an override. I think it's reasonable to ask libc6
to carry an override for weird special cases like libpcprofile.so and
libSegFault.so, since in general we don't want people packaging shared
libraries that can't be represented in shlibs.
Currently, due to how Lintian works internally, this also excludes all
such files from symbols checks as well. If that's not correct, please let
me know.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: