Ulf Herrman 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 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 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 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 . 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