bug#65665: [PATCH] Really get all the implicit inputs.

[Ulf Herrman <striness@tilde.club>]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Ulf Herrman <striness@tilde.club> writes:

> Anyway, I've since forgotten exactly what happened and why (I didn't
> actually write the commit message until quite some time later), but I
> do know that this patch fixed it.
>
> I might try to rediscover what the problem was later, but thought it
> would be good to make you aware of this so as to hopefully consolidate
> world rebuilds.

I've since done some more checking to recall what the problem actually
was, and it indeed manifested as a combination of an icecat and mesa
problem: the wrap-program phase of icecat-minimal uses
`this-package-input' to get the mesa to point LD_LIBRARY_PATH to.
However, it then stuffs the resulting package inside a <file-append>
object, which we don't currently recurse through, so it ends up
compiling with one mesa and using another at runtime, which somehow
causes a segmentation fault.

Having looked at it again, I'm not sure that rebinding `this-package' is
the best solution - it's certainly not a general solution, since any old
package could be shoved into a <file-append> object (or really any
declarative file-like object) and thereby be hidden from
transformations.  My understanding is that packaging guidelines already
discourage directly substituting top-level package references,
preferring instead tools like `this-package-input' so as to work nicely
with transformations.  If those guidelines are adhered to, the
aforementioned patch should fix issues of this nature.  I'm not sure
what the best way of handling objects like <file-append> and such is,
but as long as package references go through `this-package', it should
only matter for implicit inputs, and I don't think any of them use
declarative file-like objects other than <package>.

After thinking about it some more, I think it would be good if we had a
way of testing to make sure that every package is "transformable": that
is, if you apply a deep transformation to it, and lower the result to a
derivation, at no point within the dynamic extent of that lowering is a
derivation from an untransformed package introduced.  This would allow
for testing for transformability en masse, and could be added to 'guix
lint'.

- Ulf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]