'--with-input', '--with-git-url' etc. cause unnecessary rebuilds

Hello,

Consider this example:

Since GLib does not depend on Inkscape, the ‘--with-input’ flag should

have no effect: we should get the same glib derivation. However, we’re

not.

If we diff the ‘glibc-2.60.6-guile-builder’ files of each derivation, we

see that the second one has a duplicate entry:

(define %build-inputs

`(…

("python" . "/gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4")

("python" . "/gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4")

…))

whereas the first one doesn’t have this duplicate entry. IOW, the two

derivations are functionally equivalent but are not bit-identical.

Indeed, evaluating:

(bag-transitive-inputs

(package->bag ((package-input-rewriting '()) glib)))

shows that we have two “python” packages there that are not ‘eq?’.

To be continued…

Ludo’.

Hi,

Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

The problem is that ‘glib’ depends on ‘python-libxml2’, which uses

‘python-build-system’ and thus has ‘python’ as an implicit input.

‘package-input-rewriting’ doesn’t touch implicit inputs so it leaves

that implicit ‘python’ untouched.

Since ‘transitive-inputs’ (used by ‘bag-transitive-inputs’) uses pointer

equality, we end up with two “python” packages that are not ‘eq?’ but

are functionally equivalent: the one produced by

‘package-input-rewriting’, and the implicit dependency of

‘python-libxml2’. QED.

(This is essentially the same as https://bugs.gnu.org/30155.)

I’m not sure how to address it.

Ludo’.

merge 38100 42156

quit

severity 38100 important

quit

retitle 42156 '--with-input', '--with-git-url' etc. cause unnecessary rebuilds

quit

Hey there!

Ludovic Courtès <ludo@gnu.org> skribis:

Good news, this is fixed by 2bf6f962b91123b0474c0f7123cd17efe7f09a66,

which introduces package rewriting including implicit inputs!

Before getting there, this issue did get on my nerves for a while. Here

are several ways to address this issue that I thought of:

1. Have ‘package-input-rewriting/spec’ traverse implicit inputs, at

least optionally. We wouldn’t end up with an

equivalent-but-not-eq? ‘python’ in the example above. It does

change the semantics though, and it may be nice to keep a “shallow”

replacement option. That’s what

2bf6f962b91123b0474c0f7123cd17efe7f09a66 does.

2. Do (delete-duplicates input-drvs) in ‘bag->derivation’. That seems

wise, but it’s unfortunately impossible on ‘master’ because of

https://issues.guix.gnu.org/43508.

3. ‘package-input-rewriting/spec’ preserves eq?-ness for packages not

transformed; in the example above, the transformation result would

be eq? to ‘glib’ because ‘--with-input=libreoffice=inkscape’ had no

effect. Tricky to implement efficiently, perhaps not worth it.

I think #2 might still be worth investigating, but it may have

undesirable implications too. #3 is hardly doable.

All in all, I’m glad that #1 addresses the issue, because it’s also

something we wanted anyway.

Ludo’.