Raphael Hertzog <hert...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org