From nobody Sat Nov 11 02:25:43 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SS00n3Df8z50Rlp for ; Sat, 11 Nov 2023 02:25:45 +0000 (UTC) (envelope-from john_freebsd-ports@radioprosciutto.org) Received: from twaddle.saltant.net (twaddle.saltant.net [71.126.65.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SS00n2lymz4WMh for ; Sat, 11 Nov 2023 02:25:45 +0000 (UTC) (envelope-from john_freebsd-ports@radioprosciutto.org) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2602:fed2:7126:6000:6d7c:f8fc:79c7:8c2e] (unknown [IPv6:2602:fed2:7126:6000:6d7c:f8fc:79c7:8c2e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by twaddle.saltant.net (Postfix) with ESMTPSA id 3744E7201; Fri, 10 Nov 2023 21:25:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=radioprosciutto.org; s=twaddle2021; t=1699669544; bh=g0vYCeltfK09p9CzJ/1KyBM+qlxJ4p2gjImG0EOXILc=; h=Date:From:Subject:Reply-To:To:References:In-Reply-To; b=CAQmSfaiDvZmiIwho/VlPl7+cYasBkI9zEEDCn+xxDiPMTwu2govRzEUXn1b2i3x5 g8af/5QoC2OW2GT0oAZm77G21t62X5hdeNx2gOJDs7zRtqPRb2Wd9VUUBhVofjS/5L EeNqtREmwAteQXOYGUsGHnZtU/mB/7PffcpSyZ4sjatDWtnziwc/lgOOXcZ0+1XKqG 9qT3LFLFQbuuzJYTJpf9g13oJUgB9Ynnt8qbg/Ldrc70wKxHm/7HtrFBGmUYmTXsbw GBjgXcuZoz4TGgYpV+RPSEnOFFiNi6LtmbE0hizBUeqFkqikAzD9SSYhw24HKqpvR6 7GZ/eUMQsp5nw== Message-ID: <1271b099-2709-4c18-ad3d-d0475ed4c05f@radioprosciutto.org> Date: Fri, 10 Nov 2023 21:25:43 -0500 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: "John W. O'Brien" Subject: Re: pkg check -B tcpdump: libcap_dns.so.2 not found Reply-To: "John W. O'Brien" To: Tatsuki Makino , FreeBSD Ports References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:701, ipnet:71.126.64.0/18, country:US] X-Rspamd-Queue-Id: 4SS00n2lymz4WMh 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