Hello,
Thanks for working on it!
Josselin Poiret <d...@jpoiret.xyz> skribis:
> This is only a WIP as there are some unresolved things: I've disabled
> authentication, since I'm currently testing my own unsigned patches.
> Should we indiscriminately enable it? This would cause some issues
> for people that have their own 'guix channel. Maybe we could enable
> authentication if the channel URL is the default one?
How about adding a keyword argument to ‘channel-build-system’,
defaulting to true?
> Also, when I tried to replace the guix in the installer by
> (current-guix), it ended up building the Guix derivation multiple
> times, even though the package is memoized and the package->derivation
> process should be cached.
‘current-guix’ returns a fresh package object every time it’s called:
(define-public current-guix
(lambda ()
…
(package …)))
This defeats the object-to-derivation cache, which relies on object
identity (eq?). So yes, you definitely have to turn it into ‘mlambda’.
Why that’s no enough, I don’t know.
> There's a bit of rift between what the ci uses (renamed here to
> channel-profile-build-system) and what current-guix uses, since the
> former builds a profile as a package, whereas the latter simply builds
> the derivation for the 'guix channel. This avoids creating profile
> collisions when the package is added to the system profile, but it
> also means we don't get the package cache generation.
As discussed on IRC, I think the file-level collisions are fine: unless
I’m mistaken, it’s the ‘manifest’ file of the real profile that “wins”,
so it doesn’t really matter that the ‘guix’ package also provides a
‘manifest’ file.
What’s more problematic though is that it means that
“/run/current-system/profile/bin/guix describe” would now fail (I think?
Can you confirm?) since it gets its provenance data from the profile
it’s in.
WDYT?
Ludo’.
