You are not logged in.
When I do pacman -Syu, I often see that a package X is being upgraded, but not all packages which have X as a dependency are upgraded within the same transaction. I wonder how it is decided that if a package Y, which depends on X, should be updated or not (in the repository) when the package X is upgraded. Does the Y-package maintainer do the check manually each time? Or is this check somehow automated?
This is not just out of interest, but also for practical purposes. I have few custom packages installed manually (without pacman), and they depend on packages from official repos. If some of those official packages are upgraded within the last pacman -Syu, then how do I decide if I should recompile and upgrade the custom packages? I could do that each time after pacman -Syu, of course, but it takes hours to recompile them, and most probably not every update of a dependency requires that, so I could save time.
Last edited by Galicarnax (2023-02-18 06:54:35)
Offline
Archlinux builds packages using shared libraries. The ABI (Application Binary Interface) version those libraries support is indicated by a soname .
When the ABI changes, the soname changes. Every application that relies on that library needs to be rebuild .
lldtree (comes with pax-utils) is very handy to see which sonames a binary depends on .
example
$ lddtree /usr/bin/ls
/usr/bin/ls (interpreter => /lib64/ld-linux-x86-64.so.2)
libcap.so.2 => /usr/lib/libcap.so.2
libc.so.6 => /usr/lib/libc.so.6
$
$ pacman -Qo /usr/lib/libcap.so.2 /usr/lib/libc.so.6
/usr/lib/libcap.so.2 is owned by libcap 2.67-1
/usr/lib/libc.so.6 is owned by glibc 2.37-2
$
So if libcap or glibc change to a different library version, their soname changes and the ls binary needs to be rebuild .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks for the explanation. Are shared libraries the only mechanism behind dependencies in Arch repos? E.g. an executable from one package could simply call (fork) an executable from another package, with some arguments, and the meaning of those arguments could change from one version to another.
Last edited by Galicarnax (2023-02-19 04:20:59)
Offline