Hi Ludo, thanks for taking a look!
Ludovic Courtès <l...@gnu.org> writes:
> So while I think the feature is much welcome, I believe we should strive
> for an implementation that doesn’t break abstractions.
I agree. I would rather have a procedure which respects abstractions.
> As I mentioned earlier, one option would be to apply transformations at
> the derivation-level: take the OS derivation and use ‘map-derivation’ to
> map, say, the derivation of one package to another one. The advantage
> is that we’re guaranteed to not miss a single package; the downside is
> that it’s low-level and might not perform well.
I didn't know about that procedure, seems adequate for the job. I'm
trying to experiment with it but it does not seem to behave as I would
expect. For instance, I'm facing this error:
--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> (use-modules (guix)
(guix derivations)
(gnu packages)
(gnu packages perl)
(gnu packages games))
scheme@(guix-user)> (with-store store
(let ((cowsay-drv (package-derivation store cowsay))
(perl-drv (package-derivation store perl))
(perl-5.6-drv (package-derivation store perl-5.6)))
(map-derivation store
cowsay-drv
`((,perl-drv . ,perl-5.6-drv)))))
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure fport_read: Is a directory
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guix-user) [1]>
--8<---------------cut here---------------end--------------->8---
If you inspect the `cowsay` derivation, you will see that the mapping
should be possible since it contains the `perl` derivation.
Am I doing something wrong?
PS: Does `map-derivation` recurse into child derivations or the mapping
only affects the immediate fields of the derivation?
Have a nice Sunday!
Sergio.
