Subject: bug#75510: Building grub-image.png.drv fails with rsvg

From: vicvbcun <[email-masked]>
Date: Sun, 26 Jan 2025 23:42:17 +0100

Hello Guix!

I think that I now have some understanding for how these differently 
grafted packages can arise: The grafting code in `bag-grafts' uses 
`fold-bag-dependencies' to collect all the replacements that could 
affect a package.  That function visits all packages in the dependency 
tree depth first and exactly once.  Consider the following example tree:

A → C, B

B → D, C

Package A references packages C and B while package B references D and 
C, in that order.  If both C and D have replacements, then the grafting 
order for package B depends on whether we are considering it on its own 
or as a dependency of package A.  See also the attached dummy packages.

I think that the correct solution to this problem is to sort the grafts 
somewhere before ungexp'ing them in `graft-derivation/shallow'.  While 
package inputs should be sorted by name, they are split into `inputs', 
`native-inputs' and `propagated-inputs', build systems can add packages 
and G-expressions inputs are sorted by lexical appearance.

However the issue with guile-cairo and guile-rsvg seems to be a bit 
different. `fold-bag-dependencies' only considers packages and changes 
to rust-ring turn its source into a package, causing 
`fold-bag-dependencies' to inspect the dependencies.  Specifically, on 
aarch64-linux `fold-bag-dependencies' the following packages and outputs 
are visited near the end:
--8<---------------cut here---------------start------------->8---
[email-masked]:out        gnu/packages/crates-crypto.scm:4207
[email-masked]:out                   gnu/packages/llvm.scm:241
[email-masked]:lib                     gnu/packages/gcc.scm:743
[email-masked]:out                       gnu/packages/gcc.scm:1404
[email-masked]:out       gnu/packages/gcc.scm:1068
[email-masked]:out               gnu/packages/gcc.scm:965
[email-masked]:out                      gnu/packages/multiprecision.scm:139
[email-masked]:out                 gnu/packages/elf.scm:54
[email-masked]:out           gnu/packages/llvm.scm:145
[email-masked]:out                      gnu/packages/golang.scm:822
[email-masked]:out                     gnu/packages/golang.scm:486
[email-masked]:out      gnu/packages/golang.scm:117
[email-masked]:lib                     gnu/packages/commencement.scm:3227
[email-masked]:out                     guix/build-system/gnu.scm:151
[email-masked]:out                     gnu/packages/commencement.scm:3460
[email-masked]:out              gnu/packages/commencement.scm:3453

; note this visit to glibc!
[email-masked]:out                     gnu/packages/commencement.scm:3103
[email-masked]:static                  gnu/packages/commencement.scm:3103

[email-masked]:out             gnu/packages/base.scm:778
[email-masked]:out                      gnu/packages/algebra.scm:668
[email-masked]:out                      gnu/packages/text-editors.scm:123
[email-masked]:out                      gnu/packages/compression.scm:703
--8<---------------cut here---------------end--------------->8---

Notice the visit of glibc.  It is also visited earlier but not 
recognized as duplicate by `fold-bag-dependencies', even though it maps 
to the same derivation (This is `glibc-final', there also is a version 
of glibc created by `package-with-bootstrap-guile' earlier).  expat is 
visited before without any change.  The packages with replacements are 
cons'ed so that glibc ends up in front of expat in the grafting order. 
guile-cairo doesn't depend on rust-ring and it just so happens that 
glibc is visited before expat and they and up in the opposite order.

I don't know where these different versions of glibc come from, but 
sorting grafts should also get rid of any problems they might pose.

So why doesn't the bug appear on x86_64-linux?  Here the change only 
causes the visits of `fold-bag-dependencies' up to gawk, in particular 
the visit to glibc doesn't happen and for both guile-cairo and 
guile-rsvg expat ends up in front of glibc in the grafting order.  This 
should be related to the full-source bootstrap.

vicvbcun