BACKUP_LIBRARIES issue

Following up on my previous mail, since libraries saved to compat/pkg just
broke Samba on my system after an upgrade:

$ ldconfig -r
search directories:
/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg:/usr/local/lib/compat:/usr/local/lib/dovecot:/usr/local/lib/expect5.45.4:/usr/local/lib/gcc10:/usr/local/lib/gcc9:/usr/local/lib/graphviz:/usr/local/lib/mysql:/usr/local/lib/mysql/plugin:/usr/local/lib/perl5/5.32/mach/CORE:/usr/local/lib/pth:/usr/local/lib/qt5:/usr/local/lib/samba4:/usr/local/lib/signon:/usr/local/lib/signon/extensions:/usr/local/lib/wine:/usr/local/llvm10/lib:/usr/local/llvm11/lib:/usr/local/llvm12/lib:/usr/local/llvm13/lib:/usr/local/llvm70/lib:/usr/local/llvm80/lib:/usr/local/llvm90/lib:/usr/local/share/chromium:/usr/local/share/code-oss:/usr/local/share/electron12

Since /usr/local/lib/compat/pkg is the 5th element in the search path,
/usr/local/lib/samba4 the 17th, the same-name libraries in the compat/pkg
directory take precedence over the newly installed libraries in the
samba4 directory.

Since paths are added to the search list at the end, when new packages
are installed, lib/compat/pkg may end up in the middle of the search
path, even when it was at the end at boot time.

I see 2 possible solutions:

1) Make sure that compat library paths come last (e.g. by adding a new
   option letter to specify compat library paths: ldconfig -b compat/pkg).
   Or special-case compat paths in ldconfig to implicitly add them only at
   the end of a search path (without requiring a new option letter).

2) Make the pkg command remove libraries from the compat/pkg directory
   if a same-name library is installed in some other system directory.

Without such a safe-guard, software that installs libraries with internal
interface version numbers/checks under the same name as previous incompatible
versions (e.g. samba, dovecot, ...) will fail to start.

Am 08.11.21 um 17:28 schrieb Stefan Esser:
> Am 08.11.21 um 16:06 schrieb Baptiste Daroussin:
>> On Mon, Nov 08, 2021 at 04:03:56PM +0100, freebsd@ohreally.nl wrote:
>>> Thank you, Stefan.
>>> I am creating an issue at the portupgrade/pkgtools GitHub project as we
>>> speak. I will include all the information that Baptiste and you have given
>>> me.
>>>
>>> Best,
>>>   Rob
>>>
>>
>> Just the "No such file or directory @ rb_check_realpath_internal" shows it comes
>> from portupgrade and not pkg itself, I missed it in my first review.
>>
>> Note that portmaster and portupgrade do not need to support that feature anymore
>> as it is provided by pkg directly (they just need to activate it or not if they
>> wants for backward compatibility).
> Hi Baptiste,
> 
> thank you for the information, I did not know about BACKUP_LIBRARIES.
> 
> But I think that the functionality is somewhat different. Portmaster
> creates a copy of a local library before invoking "pkg delete" to keep
> it around for any ports that still depend on it.
> 
> If a port is being upgraded and a library with the same name is
> installed to /usr/local/lib, the backup in compat/pkg will be deleted.
> 
> AFAIUI, the effect of BACKUP_LIBRARIES, it has no effect on any command
> besides "pkg add", and it specifically does not protect against the removal
> of a shared library that is still required by some installed package.
> It does not appear to have any effect if "make install" is used to install
> a port (since that only uses "pkg register", not "pkg add".)
> 
> The pkg command could check whether any of the libraries to be deleted
> by "pkg delete" is still depended on by any other package (i.e. in the
> list generated by "pkg query %B") and then copy it to compat/pkg, if
> still being depended on.
> 
> OTOH if a new package is installed, any library in compat/pkg that is
> in the list of newly installed libraries can be removed from compat/pkg.
> 
> This is important, since I found that "ldconfig -m" tends to add newly
> created shared library locations to the end of the search path, and as
> a result if a shared library has been saved to compat/pkg, it will take
> precedence over a newly installed one. Therefore, removal of libraries
> from compat/pkg is required in that case, to make the newly installed
> libraries accessible.
> 
> Regards, STefan
> 
> PS: The documentation of BACKUP_LIBRARIES in pkg.conf(5) is not
> very precise. And this parameter could be added to the list of
> environment variables checked by "pkg add" in pkg-add(8).
>