On 07/10/24 16:07, Mark Millard wrote:
On Oct 7, 2024, at 11:34, Renato Botelho <[email protected]> wrote:

On 07/10/24 14:49, Mark Millard wrote:
Renato Botelho <garga_at_FreeBSD.org> wrote on
Date: Mon, 07 Oct 2024 14:20:00 UTC :
On 07/10/24 03:53, Baptiste Daroussin wrote:
Hello everyone,

Just a reminder when using pkgbase, make sure you do activate
BACKUP_LIBRARIES=true in pkg.conf

This way pkg will save a copy of libmd.so.6 during the upgrade in
/usr/local/lib/pkg/libmd.so.6 (and create a package named compat-libraries to
track it).

This will prevent you from having a couple of days without a new version of pkg
built against libmd.so.7 available (or some of the packages which also requires
libmd.so.7.

I have BACKUP_LIBRARIES=true on my pkg.conf and upgraded a system
running CURRENT this morning using pkgbase. After that I got pkg linked
with both libmd.so.6 and libmd.so.7:

root@x230:~ # ldd /usr/local/sbin/pkg
/usr/local/sbin/pkg:
libelf.so.2 => /lib/libelf.so.2 (0x28b8027a6000)
libjail.so.1 => /lib/libjail.so.1 (0x28b80340b000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x28b80436a000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x28b804e18000)
libarchive.so.7 => /usr/lib/libarchive.so.7 (0x28b805e0a000)
libbz2.so.4 => /usr/lib/libbz2.so.4 (0x28b80710e000)
libz.so.6 => /lib/libz.so.6 (0x28b807ccc000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28b808368000)
libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5
(0x28b806205000)
libm.so.5 => /lib/libm.so.5 (0x28b808952000)
libutil.so.9 => /lib/libutil.so.9 (0x28b808ad1000)
libmd.so.6 => not found (0)
libthr.so.3 => /lib/libthr.so.3 (0x28b809f4c000)
libc.so.7 => /lib/libc.so.7 (0x28b80ae53000)
libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x28b80c034000)
libmd.so.7 => /lib/libmd.so.7 (0x28b80cdf7000)
libsys.so.7 => /lib/libsys.so.7 (0x28b80ddb1000)
[vdso] (0x28b801eee000)
. . .
It would help for tracking down were the dependencies are
to use "ldd -a ". It shows what each involved *.so.*
in turn references of itself. The example below is for
a context that does not have the problem you report
(not a pkgbase context) but it illustrates the type of
extra information that is output:
# ldd -a /usr/local/sbin/pkg
/usr/local/sbin/pkg:
libelf.so.2 => /lib/libelf.so.2 (0xc4840f00000)
libjail.so.1 => /lib/libjail.so.1 (0xc48410d3000)
libssl.so.30 => /usr/lib/libssl.so.30 (0xc4841fae000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0xc4842853000)
libarchive.so.7 => /usr/lib/libarchive.so.7 (0xc4843af6000)
libbz2.so.4 => /usr/lib/libbz2.so.4 (0xc48403f6000)
libz.so.6 => /lib/libz.so.6 (0xc4845351000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0xc48455b0000)
libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0xc484480f000)
libm.so.5 => /lib/libm.so.5 (0xc48463e4000)
libutil.so.9 => /lib/libutil.so.9 (0xc4846b3d000)
libmd.so.7 => /lib/libmd.so.7 (0xc48477f3000)
libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libelf.so.2:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libjail.so.1:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/usr/lib/libssl.so.30:
libcrypto.so.30 => /lib/libcrypto.so.30 (0xc4842853000)
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libcrypto.so.30:
libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/usr/lib/libarchive.so.7:
libz.so.6 => /lib/libz.so.6 (0xc4845351000)
libbz2.so.4 => /usr/lib/libbz2.so.4 (0xc48403f6000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0xc48455b0000)
libbsdxml.so.4 => /lib/libbsdxml.so.4 (0xc4849553000)
libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0xc484480f000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0xc4842853000)
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/usr/lib/libbz2.so.4:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libz.so.6:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/usr/lib/liblzma.so.5:
libmd.so.7 => /lib/libmd.so.7 (0xc48477f3000)
libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/usr/lib/libprivatezstd.so.5:
libthr.so.3 => /lib/libthr.so.3 (0xc4848518000)
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libm.so.5:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libutil.so.9:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libmd.so.7:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
/lib/libthr.so.3:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
libsys.so.7 => /lib/libsys.so.7 (0xc484af47000)
/lib/libc.so.7:
libsys.so.7 => /lib/libsys.so.7 (0xc484af47000)
/lib/libbsdxml.so.4:
libc.so.7 => /lib/libc.so.7 (0xc484889d000)
[preloaded]
[vdso] (0xc483f927000)
I expect that /usr/local/sbin/pkg has the only reference
to libmd.so.6 in your context and that /usr/lib/liblzma.so.5
is what is referencing libmd.so.7 .
If so, I'll note that you can avoid the problem by using
pkg-static instead of pkg as your command:
# ldd -a /usr/local/sbin/pkg-static
ldd: /usr/local/sbin/pkg-static: not a dynamic ELF executable
So there is no use of *.so.* files for pkg-static .
(I make no claims about other programs that might be involved
overall.)

I've fixed it by building pkg on local ports tree.  But anyway I've forced a 
bootstrap to have the one provided by official repository installed again and 
ran ldd -a to collect data

root@x230:~ # ldd -a /usr/local/sbin/pkg
/usr/local/sbin/pkg:
        libelf.so.2 => /lib/libelf.so.2 (0x1a55a0de2000)
        libjail.so.1 => /lib/libjail.so.1 (0x1a55a1fae000)
        libssl.so.30 => /usr/lib/libssl.so.30 (0x1a55a1fc2000)
        libcrypto.so.30 => /lib/libcrypto.so.30 (0x1a55a2e3a000)
        libarchive.so.7 => /usr/lib/libarchive.so.7 (0x1a55a3e98000)
        libbz2.so.4 => /usr/lib/libbz2.so.4 (0x1a55a4a17000)
        libz.so.6 => /lib/libz.so.6 (0x1a55a4d85000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x1a55a57ed000)
        libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0x1a55a640f000)
        libm.so.5 => /lib/libm.so.5 (0x1a55a696c000)
        libutil.so.9 => /lib/libutil.so.9 (0x1a55a6e12000)
        libmd.so.6 => not found (0)
        libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libelf.so.2:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libjail.so.1:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libssl.so.30:
        libcrypto.so.30 => /lib/libcrypto.so.30 (0x1a55a2e3a000)
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libcrypto.so.30:
        libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libarchive.so.7:
        libz.so.6 => /lib/libz.so.6 (0x1a55a4d85000)
        libbz2.so.4 => /usr/lib/libbz2.so.4 (0x1a55a4a17000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x1a55a57ed000)
        libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x1a55a834a000)
        libprivatezstd.so.5 => /usr/lib/libprivatezstd.so.5 (0x1a55a640f000)
        libcrypto.so.30 => /lib/libcrypto.so.30 (0x1a55a2e3a000)
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libbz2.so.4:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libz.so.6:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/liblzma.so.5:
        libmd.so.7 => /lib/libmd.so.7 (0x1a55a853a000)
        libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/usr/lib/libprivatezstd.so.5:
        libthr.so.3 => /lib/libthr.so.3 (0x1a55a7a49000)
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libm.so.5:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libutil.so.9:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libthr.so.3:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
        libsys.so.7 => /lib/libsys.so.7 (0x1a55a8908000)
/lib/libc.so.7:
        libsys.so.7 => /lib/libsys.so.7 (0x1a55a8908000)
/lib/libbsdxml.so.4:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
/lib/libmd.so.7:
        libc.so.7 => /lib/libc.so.7 (0x1a55a7aa9000)
[preloaded]
        [vdso] (0x1a559fe96000)

It seems pkg is still linked with libmd.so.6 and lzma is linked with libmd.so.7.

So, as I expected. Good to know.

Anyway we have a problem, keeping libmd.so.6 seems not to be enough to have pkg 
working

Typing/using pkg-static instead of pkg should not fail
for libmd.so.6 or libmd.so.7 reasons for its down
execution, even when using just pkg would fail for
such. An example usage is:

# pkg-static  info -l pkg | grep /sbin/
/usr/local/sbin/pkg
/usr/local/sbin/pkg-static

The above should work even in a context with the
libmd.so.6 problem for using just pkg . (The
/usr/bin/grep part should work too.)

For reference (the context does not have the
libmd.so.6 problem):

# pkg  info -l pkg | grep /sbin/
/usr/local/sbin/pkg
/usr/local/sbin/pkg-static

Personally, my scripts that use pkg actually run
pkg-static so that the script is less dependent
on the environment for reasonable operation.

Yes, I know about pkg-static and I also managed to use it when needed. My point is the main message of the original email about using BACKUP_LIBRARIES=true, which says:

This will prevent you from having a couple of days without a new version of pkg built against libmd.so.7 available (or some of the packages which also requires libmd.so.7.

And in fact it's not true. Even if you have libmd.so.6 on your system, pkg is broken.
--
Renato Botelho


Reply via email to