graceful handling of library upgrades

[v4hn]

This has gotten on my nerves dozen of times by now every time I do not manage to update for a while and end up with 30-100 packages to be updated.

Lunar does not preserve libraries, just because they are still used.
If a package is updated, libraries get overwritten and the old ones get removed, leaving downstream dependencies dangling with broken links.

Of course, lunar fix scans installed libraries for unresolved library dependencies and rebuilds affected packages.

Still, I do not really see a problem if we handle this in a more graceful way.

I would propose to

• move SONAMEed libraries to /usr/lib*/OBSOLETE/ and add this folder to /etc/ld.so.conf
• have lunar fix scan for libraries that resolve to this subfolder and treat them the same way we treat Not found
• If libraries in the folder are found not to be in use anymore, lunar fix or lunar prune could clean them.

What do you think @Ratler @florin65 @dagbrown ?

[florin65]

Good idea. I'm for it.

[Ratler]

I agree, it is really annoying. Your proposal could actually work. I think we should put them in /usr/lib/lunar/OBSOLETE to follow the lunar way of handling namespaces. I can create a branch and begin doing the changes required.

[Ratler]

Just a quick proof-of-concept. Working on the cleanup code now.

root@ladyvox ~ # lunar nofix openssh

/usr/bin/scp of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007ff9e8b5b000)
/usr/bin/sftp of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007f4b9165a000)
/usr/bin/ssh of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007fc8ebbea000)
/usr/bin/ssh-add of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007f7c3d804000)
/usr/bin/ssh-agent of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007feca26bf000)
/usr/bin/ssh-keygen of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007ff4eefea000)
/usr/bin/ssh-keyscan of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007f695476a000)
/usr/libexec/sftp-server of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007f76eeef0000)
/usr/libexec/ssh-keysign of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007fe218a1c000)
/usr/libexec/ssh-pkcs11-helper of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007fc0c5f5b000)
/usr/sbin/sshd of openssh is broken.
libcrypto.so.45 => /usr/lib/lunar/OBSOLETE/libcrypto.so.45 (0x00007ff0a5cc3000)

Lunar nofix completed at Mon 10 Feb 2020 11:40:41 PM WET
Successful : 0
Failed : 0

root@ladyvox ~ # ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
[-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
[-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J [user@]host[:port]] [-L address]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-Q query_option] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command]

root@ladyvox ~ # lin -c openssh

root@ladyvox ~ # lunar nofix openssh

Lunar nofix completed at Mon 10 Feb 2020 11:42:28 PM WET
Successful : 0
Failed : 0

root@ladyvox ~ # ldd /usr/bin/ssh
linux-vdso.so.1 (0x00007ffe10fbc000)
libcrypto.so.43 => /usr/lib/libcrypto.so.43 (0x00007f600d1b2000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f600d1ad000)
libutil.so.1 => /lib/libutil.so.1 (0x00007f600d1a8000)
libz.so.1 => /lib/libz.so.1 (0x00007f600cf91000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f600cf57000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f600cf3e000)
libc.so.6 => /lib/libc.so.6 (0x00007f600cdb5000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f600cd93000)
/lib64/ld-linux-x86-64.so.2 (0x00007f600d47a000)

[v4hn]

Just a quick proof-of-concept. Working on the cleanup code now.

Wow! I didn't expect anyone to spring into action like that! 🚀
This will safe a lot of frustration in the long run...

[v4hn]

So the committed features do work as expected over here with a few known issues:

• some logic in lunar calls lrm <module> in contexts where the package will really be replaced by something else later. e.g., changing the %OSSL alias from openssl to libressl, or the qt5/PRE_BUILD running lrm qt5
  These calls should add a new flag, e.g., --keep-obsolete-libs to backup the libraries in this case
• /usr/lib/lunar/OBSOLETE is only cleaned when all tests run without issues, but it should only care about the ld checks. Especially changed checksums are a pest to get rid of at times.
• I believe currently nothing automatically adds /usr/lib/lunar/OBSOLETE to the ldconfig files. That was probably the motivation for fhs: update ld.so.conf and create ld.so.conf.d/ moonbase-core#2426?

[v4hn]

I just hit another issue with the patch that can send lunar fix into an endless loop.

Going from xz 5.2.4 to xz 5.2.5:

$ ls /lib/liblzma.so* -hl
lrwxrwxrwx 1 root root   16 Apr 20 21:38 /lib/liblzma.so -> liblzma.so.5.2.4
lrwxrwxrwx 1 root root   16 Apr 20 21:38 /lib/liblzma.so.5 -> liblzma.so.5.2.4
-rwxr-xr-x 1 root root 179K Apr 20 21:38 /lib/liblzma.so.5.2.4
$ lin xz
...
$ ls /lib/liblzma.so* -hl
lrwxrwxrwx 1 root root   16 Apr 20 21:39 /lib/liblzma.so -> liblzma.so.5.2.5
lrwxrwxrwx 1 root root   16 Apr 20 21:39 /lib/liblzma.so.5 -> liblzma.so.5.2.5
-rwxr-xr-x 1 root root 179K Apr 20 21:39 /lib/liblzma.so.5.2.5
$ ls /usr/lib/lunar/OBSOLETE/liblzma.so.5* -l
lrwxrwxrwx 1 root root     16 Apr 20 21:39 /usr/lib/lunar/OBSOLETE/liblzma.so.5 -> liblzma.so.5.2.4
-rwxr-xr-x 1 root root 182664 Apr 20 21:39 /usr/lib/lunar/OBSOLETE/liblzma.so.5.2.4

liblzma.so.5 should not be backed up in this case because the same library is still reinstalled, right?
adding /lib to the top of /etc/ld.so.conf solved the problem for me (it was not listed there before and thus apparently is the last fallback?

Was the missing path in the ld.so.conf just a quirk on my system?
It's probably a good idea to filter the old libraries for libs with the same name in the installed files?