bug#53406: union-build incorrectly handles grafts

[John Kehayias]

Hello Guix,

Stumbled upon a mysterious problem today with grafts. Let me report what I see 
and how to reproduce it:

I'm attaching a minimal working example of the problem, namely using 
union-build creates the wrong symlink when a package has a propagated input 
that has a replacement. At least that seems to be the key ingredients. (Note 
the code originally came from another channel, so I left the header intact. The 
union-build looks the same as in e.g. python-pyqt+qscintilla though.)

It looks like a link is made to a wrong (i.e. previous) version library. It is 
pointing to the replacement package in the store, but trying to use the 
previous name.

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).

There are no error or warnings that I saw in building the package or in a 
profile (e.g. guix shell). I put in an output in the builder to see what 
directories were passed to the union-build, giving me

directories: (/gnu/store/d0xskl9xjb0z6miaf87xszi8iq6h8sqs-apr-util-1.6.1 
/gnu/store/iwcw80p8lkqsqbvchjvypvl06qlbjc3d-expat-2.4.1)

So the original expat propagated-input store directory is passed to the builder 
(as expected), but in the end it does use the replacement version. Just with a 
version number gone wrong in a library link.

I came across this actually when combining both x86_64 and i686 into a single 
profile. There it would error on a conflict between file and directory, but in 
the lib/cmake of expat, again something with different version numbers 
appearing but between x86_64 and i686. I don't have an example of that handy 
right now, but it sent me in the direction of seeing why expat was coming up, 
when I came across this (I'm guessing leading to the problem I saw).

In case it is relevant, I did notice other packages have had explicit 
replacements used in propagated inputs previously, like in 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c5df560fd3762c0dbe99562f52223c73d445e597
 expat is propagated by fontconfig and apr-util, possibly other places? A bit 
tricky to search with the expat license and all.

This was on commit: e415a73d2c11e43f4db3b797ed73ab6ebcc336e0 My original 
problem (conflict in x86_64 and i686 union) happened after the expat 
replacement commit, 2045852b096131a714409aa0cc4fe17938f60b15 which was my first 
clue.

I hope that is helpful in reproducing and finding out what is happening. 
Something to do with union-build I guess, but it is very late here right now so 
I hope this all made sense. Happy to help investigate and debug.

John

graft-test.scm
Description: Text Data