[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65665: [PATCH] Really get all the implicit inputs.
From: |
Ulf Herrman |
Subject: |
bug#65665: [PATCH] Really get all the implicit inputs. |
Date: |
Fri, 06 Oct 2023 22:47:04 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
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
signature.asc
Description: PGP signature