Ludovic Courtès writes: > Christopher Baines skribis: > >> Ludovic Courtès writes: >> >>> Christopher Baines skribis: >>> >>>> This allows computing a manifest for a specific system. Previously this was >>>> possible, but only through changing %current-system, which caused the >>>> derivation to be computed using that system as well (so computing a derivation >>>> for aarch64-linux on x86_64-linux would require running aarch64-linux code). >>> >>> I remember discussing it, but I wonder if I was confused. >>> >>> I think you can always do the equivalent of (say): >>> >>> guix time-machine -- build -s armhf-linux hello -d >>> >>> … where Guix itself is built natively but it then computes a derivation >>> for a different architecture. >>> >>> The equivalent code would be roughly: >>> >>> (let ((inferior (inferior-for-channels …))) >>> (inferior-package-derivation store >>> (car (lookup-inferior-packages inferior "hello")) >>> "armhf-linux")) >>> >>> Does that make sense? >> >> Not really, > > :-) > >> this is just about manifests for channel instances, so nothing to do >> with package derivations as far as I'm aware. > > I re-read your message and must have misunderstood. It’s the derivation > of channel instances that you want for a given system, right? (What’s > the use case though?) In that case something along the lines of the > patch makes perfect sense. Yep, the Guix Data Service currently uses channel-instances->manifest to compute the channel instance derivations (which show up here for example [1]. Currently it computes the derivations for different systems by setting %current-system, but this has the side effect of also running the Guile code for computing the derivation with Guile for that system. 1: https://data.guix.gnu.org/revision/afec2784174058fdd85d9698e1fa748c45bfa8ee/channel-instances That effectively only works if QEMU binfmt support is available for those other systems. It would be faster just to use the native Guile, and this would also avoid substitute availability problems (I had to disable armhf-linux emulation on the data.guix.gnu.org machine when the substitute availability from ci.guix.gnu.org got worse recently as too much time was being spent just building armhf-linux things).