Re: Building, packaging and updating Guix with confidence

[Josselin Poiret]

Hello,

Zhu Zihao <all_but_last@163.com> writes:

> If your foreign function use case is very trivial? Why not give Guile
> dynamic FFI a try?

That could be another option, but I'd like to have autoconf be able to
detect whether the target supports things like posix_spawn and
getrlimit, which I use in the code.

> It's possible to use guix channel to test a local guix repo. A short
> example here.

Right, but for the example of adding extensions it won't work since
there's a part of `guix pull` that uses the guix package, as well as in
the installer or system-wide Guix, as I outlined before.  The issue [1]
I outlined in the opening mail was an issue that is specific to the guix
package method, so there really isn't a way to uniformly test changes
without knowing the intricacies of the different builds and where they
end up (I do know these, having run into these issues myself before).

> This is somewhat "the bootstrap problem". It's very ideal if we can
> describe the build graph in Guix with derivations. But we still need a
> daemon first to process derivations. So we need to build daemon without
> Guix.

I don't think that's the case, (guix self) relies on a working daemon
connection before anything else, the built daemon will just be a part of
the resulting `guix pull` profile, but won't be used to build the new
Guix (as a matter of fact, the build daemon is built... using the build
daemon!).

> This issue may be solved by rewriting daemon in Guile. If daemon is
> written in Guile. We can run it without compilation.

I don't think this is directly related, although some changes that we
could bring to it would definitely ease what I'm proposing here: having
a way to build things directly without relying on a root-owned daemon
running would make the bootstrapping problem easier to solve.

Best,
-- 
Josselin Poiret