Re: pkg check -B tcpdump: libcap_dns.so.2 not found

On 11/10/23 16:26, Tatsuki Makino wrote:
> Hello.
> 
> John W. O'Brien wrote on 2023/11/11 02:34:
>> The pkg-check command complains that net/tcpdump is missing a shared library, but ldd correctly identifies the file, and the command runs without complaint. Does this seem like a bug in pkg? ... in net/tcpdump?
> 
> Here is roughly what I have found about the missing shlib problem after pkg-check.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261550
> 
> There may be others scattered about :)
> Where is the main one doing that?

I can reproduce the example you cite in comment 8, and yet "-d" and "-B" 
output cover disjoint packages on this system.


% sudo pkg check -d -n -a
Checking all packages: 100%
llvm15 is missing a required shared library: libz.so.6
llvm15 is missing a required shared library: libthr.so.3
llvm15 is missing a required shared library: libncursesw.so.9
llvm15 is missing a required shared library: libm.so.5
llvm15 is missing a required shared library: libkvm.so.7
llvm15 is missing a required shared library: libcxxrt.so.1
llvm15 is missing a required shared library: libc.so.7
% sudo pkg check -B -n -a
Checking all packages:  90%
(tcpdump-4.99.4_1) /usr/local/sbin/tcpdump - required shared library 
libcap_dns.so.2 not found
Checking all packages: 100%


I think that the "-d" check is an internal consistency check on the 
local pkg database to ensure that every package with a registered 
requirement on a shared library X is satisfied by another package that 
is registered as having provided library X.

For example, libz.so.6 appears in the shlibs table, and the llvm15 
package has a registered requirement for it, yet it is registered as 
being provided by zero other package.


% sqlite3 /var/db/pkg/local.sqlite
SQLite version 3.43.1 2023-09-11 12:01:27
Enter ".help" for usage hints.
sqlite> select * from shlibs where name='libz.so.6';
8214|libz.so.6
sqlite> select p.name from packages p join pkg_shlibs_required s on p.id 
= s.package_id where s.shlib_id = 8214;
llvm15
sqlite> select count(*) from packages p join pkg_shlibs_provided s on 
p.id = s.package_id where s.shlib_id = 8214;
0
sqlite>


That is, it seems like bug 261550 is about shlibs that are provided by 
base ending up being recorded in the local package database as if they 
are provided by packages. Something about how the llvm15 package is 
produced and/or how its metadata is ingested into the local package 
database results in required/provided data that is invalid.

By comparison, I think the "-B" check is not purely, or not at all, an 
internal consistency check on the local package database.

For example, libcap_dns.so.2 does not appear in the shlibs table, nor do 
any of the libcap family of shlibs, and so "pkg check -B" must be 
detecting the real requirement by looking somewhere else than in the 
local package database.


sqlite> select count(*) from shlibs where name like 'libcap%';
0


That is, it seems like the tcpdump anomaly is fundamentally different 
than the llvm15 example from bug 261550.

Would freebsd-pkg@ be a better forum for this discussion?

Regards,
John