bug#53406: union-build incorrectly handles grafts

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

John Kehayias <john.kehayias@protonmail.com> skribis:

> If I run the attached file with guix build -f graft-test.scm and look at libexpat in the created package with, e.g.
>
> ls -la $(guix build -f graft-test.scm)/lib/libexpat*
>
> I get
>
> lrwxrwxrwx 1 root root 71 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.la -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
> lrwxrwxrwx 1 root root 71 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.so -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so*
> lrwxrwxrwx 1 root root 73 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.so.1 -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1*
> lrwxrwxrwx 1 root root 77 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.so.1.8.1 -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1
>
> Note that the last link is broken: looking at this expat library (2.4.3, the replacement) it has
>
> -r-xr-xr-x 1 root root  961 Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
> lrwxrwxrwx 1 root root   17 Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so -> libexpat.so.1.8.3*
> lrwxrwxrwx 1 root root   17 Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1 -> libexpat.so.1.8.3*
> -r-xr-xr-x 2 root root 191K Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.3*
>
> This is why the last link from the union-build package is broken, it tries to point to libexpat.so.1.8.1 (the previous version, but in the newer version's directory).

Grafting is a pretty basic process: in this case it replaces occurrences
of /gnu/store/…-expat-2.4.1 with /gnu/store/…-expat-2.4.3, nothing more.
It cannot guess that libexpat.so.1.8.1 was renamed to libexpat.so.1.8.3
or anything like that.

Is it a problem?  Normally no, because users of shared libraries don’t
refer to libraries by their fully-qualified name:

--8<---------------cut here---------------start------------->8---
$ objdump -x $(guix build dbus-glib)/bin/dbus-binding-tool|grep NEED.*expat
  NEEDED               libexpat.so.1
$ objdump -x  $(guix build dbus-glib)/bin/dbus-binding-tool|grep RUNPATH
  RUNPATH              /gnu/store/wwmxxlmlhwljn39z0gsj6iai3zk67a2g-dbus-glib-0.110/lib:/gnu/store/5s6iz5f777rh23q4kv8gvqrsyy61cbjh-dbus-1.12.20/lib:/gnu/store/s0w7szfsajdy6cnrz2w7z4h5spyl4aaj-expat-2.4.1/lib:/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib:/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gcc-10.3.0-lib/lib:/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/lib:/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/../../..
--8<---------------cut here---------------end--------------->8---

Likewise, ‘etc/ld.so.cache’ contains a reference to ‘libexpat.so.1’, not
to ‘libexpat.so.1.8.1’.

Does that make sense?  Or am I overlooking something?

Thanks,
Ludo’.