Re: libmd.so.6 and pkgbase

On 07/10/24 16:07, Mark Millard wrote:
> On Oct 7, 2024, at 11:34, Renato Botelho <garga@FreeBSD.org> 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