pacman & prevention of broken binary dependencies

George_K · 2011-05-14 20:54:05

In Gentoo land, portage 2.2 integrated and enhanced functionality of the former tool revdep-rebuild into emerge. With 2.2, emerge (1) collects dependency information from dynamic binaries and libraries, (2) preserves old .so.* files on system updates as long as they are needed, (3) informs user of all preserved libraries and packages which depend on them on each system update, (4) provides a convenient way to rebuild all packages which depend on old libraries and (5) automatically removes old library files as soon as nothing depends on them.

As far as I know, this functionality is not yet implemented in pacman, even though all features except of the 4th being implemented in pacman will make sense on a system using AUR packages, and even binary package development will become easier.

Yet my understanding of Arch might be a bit obsolete. My questions are:

- what is the best current practice of dealing with packages installed from AUR when updates of libraries they depend upon happen?
- is something similar to what I've described in the beginning in the course of pacman development?

Last edited by George_K (2011-05-14 20:54:59)

tomk · 2011-05-14 21:09:03

In principle, the idea of preserving old *.so files as long as they are needed is not compatible with Arch's overall approach.

Re your specific questions:

- what is the best current practice of dealing with packages installed from AUR when updates of libraries they depend upon happen?

Rebuild and reinstall them.

- is something similar to what I've described in the beginning in the course of pacman development?

Search the pacman-dev mailing list archives for related topics. If you're up for some coding, put something together yourself and submit patches.

karol · 2011-05-14 21:36:16

AUR is (and will stay) unofficial, pacman deals with managing packages, not building them. It's makepkg's job.

George_K wrote:

what is the best current practice of dealing with packages installed from AUR when updates of libraries they depend upon happen?

http://aur.archlinux.org/packages.php?ID=34686
Scroll down to April comments about the new yajl:

Comment by: deimos on Tue, 26 Apr 2011 03:59:52 +0000
After updating to yajl-2.0.0-1, I get the following error:
lua: error loading module 'yajl' from file '/usr/lib/lua/5.1/yajl.so':
libyajl.so.1: cannot open shared object file: No such file or directory
stack traceback:
[C]: ?
[C]: in function 'require'
/usr/share/lua/5.1/clydelib/sync.lua:2: in main chunk
[C]: in function 'require'
/usr/bin/clyde:6: in main chunk
[C]: ?

Comment by: juster on Wed, 27 Apr 2011 19:52:24 +0000
Yes, you must upgrade lua-yajl in order to use yajl 2.0. Build and install the lua-yajl-git package from the AUR: http://aur.archlinux.org/packages.php?ID=48496

George_K · 2011-05-15 02:01:42

tomk wrote:

In principle, the idea of preserving old *.so files as long as they are needed is not compatible with Arch's overall approach.

The other option portage developers might likely have considered (in fact I don't know) is to collect information on packages broken due to library update without preserving *.so files — but this is less logical. The main ideas are that without this feature system update may silently leave some applications broken, and that “preserved libs” is an explicit temporary state of inconsistency after an atomic system upgrade (e.g. pacman -Su).
I'd like to know how Arch developers deal with this while packaging. (I've read about lddd and findbrokenpkgs recently, but I have not tried them and don't know how useful they are).

tomk wrote:

- what is the best current practice of dealing with packages installed from AUR when updates of libraries they depend upon happen?
Rebuild and reinstall them.

In general, this should be done in Gentoo too, because it is not guaranteed that old libraries will work with new data files (if they used them) and so on. I asked from a different perspective: How do I know that they are broken in the first place? Were I a sole user of an Arch installation, broken binaries would be but an inconvenience (try to run → fails to run with a .so not found → recompile). But I need to maintain two personal computers which I rarely use and to which I have either infrequent or remote access.

tomk wrote:

- is something similar to what I've described in the beginning in the course of pacman development?
Search the pacman-dev mailing list archives for related topics. If you're up for some coding, put something together yourself and submit patches.

I found some relevant threads (earliest dating from 2009), reading them soon… I'm not up for coding this month, but I'll consider making patches later.

karol wrote:

http://aur.archlinux.org/packages.php?ID=34686
Scroll down to April comments about the new yajl:

If you, basically, suggest to update something broken by stumbling upon it being unable to run, that's an approach I'm familiar with, and a problem I was referring to in the first post.

karol wrote:

AUR is (and will stay) unofficial, pacman deals with managing packages, not building them. It's makepkg's job.

Yes, this is why point 4 is not relevant to pacman. But I don't see a way of implementing other points outside of alpm (given that alpm frontends coexistence on a single system matters).

Last edited by George_K (2011-05-15 02:26:17)

Allan · 2011-05-15 04:28:38

George_K wrote:

I'd like to know how Arch developers deal with this while packaging.

There is a script (checkpkg in devtools) which among other things highlights an soname bump in a package update. When we see on, we generate a list of packages in the repos that link to that library and rebuild them.

Allan · 2011-05-15 04:34:37

BTW, lddd (and I think findbroken packages) both list packages that link to libraries that are not on your system so can be used to check for packages that need rebuilt. A script that only checked packages that were not from the repos would be faster... I might write one.

tomk · 2011-05-15 08:58:35

George_K wrote:

I need to maintain two personal computers which I rarely use and to which I have either infrequent or remote access.

IMO Arch needs constant attention, including frequent upgrades. In your position, I would consider an alternative distro for these boxes.

George_K · 2011-05-15 13:19:19

Not to misinform, at this moment they are running Arch and Sabayon, and I'm using Funtoo, with Sabayon and Arch ready in chroot and grub.cfg. In the second post I'm speaking from experience when all systems were running Arch.

Last edited by George_K (2011-05-15 13:25:36)

Arch Linux

#1 2011-05-14 20:54:05

pacman & prevention of broken binary dependencies

#2 2011-05-14 21:09:03

Re: pacman & prevention of broken binary dependencies

#3 2011-05-14 21:36:16

Re: pacman & prevention of broken binary dependencies

#4 2011-05-15 02:01:42

Re: pacman & prevention of broken binary dependencies

#5 2011-05-15 04:28:38

Re: pacman & prevention of broken binary dependencies

#6 2011-05-15 04:34:37

Re: pacman & prevention of broken binary dependencies

#7 2011-05-15 08:58:35

Re: pacman & prevention of broken binary dependencies

#8 2011-05-15 13:19:19

Re: pacman & prevention of broken binary dependencies

Board footer