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
