GNU bug report logs -
#65665
package-mapping with #:deep? #t doesn't get all the implicit inputs
Previous Next
Full log
Message #29 received at 65665 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ulf Herrman <striness <at> 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
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 1 year and 242 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.