Control: severity -1 minor On Fri, Nov 27, 2015 at 09:41:30AM +0100, Thorsten Glaser wrote: > | Shared libraries MUST be linked against all libraries that they use > | symbols from in the same way that binaries are. > (emphasis mine) > adequate reports: > […] > apt: undefined-symbol /usr/lib/x86_64-linux-gnux32/libapt-private.so.0.0.0 => _Z8ShowHelpR11CommandLine > apt: undefined-symbol /usr/lib/x86_64-linux-gnux32/libapt-private.so.0.0.0 => _Z11GetCommandsv > […] > > See also: Policy §8.6.1 This applies to SHARED libraries (emphasis mine), but libapt-private isn't one. Its an internal library¹ used to share code between apt, apt-get and co which is too specific to be moved into the real shared library libapt-pkg (or its ugly cousin libapt-inst), but creating "fat" binaries isn't in our best interest either. The mentioned symbols (which are implemented by the respective binary itself by the way) are the best examples for this: The --help text and which commands (like install/remove/clean) a given binary supports (and which function is used to deal with it) are of no concern for other apt-frontends and so do not need to clutter the ABI/API of libapt-pkg and even in libapt-private it makes no sense to define them as its different for all of them, but then I am lazy and don't want to maintain pretty much the same copycat calling code in each frontend… I guess to appease adequate I can pull some weak symbol magic, which I initially intended anyhow, but part forgot and part found useful while working on this change. ¹ if "-private" wasn't enough of a hint, headers aren't available, no symbols/shlibs file and exactly nobody cares about ABI/API in there. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature