Re: Building, packaging and updating Guix with confidence

[bokr]

Hi Josselin,
I have some naive questions below :)

On +2022-07-07 16:34:17 +0200, Josselin Poiret wrote:
> 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
> 

Naively:

Why does "the" guix daemon per se need root access at all?

Why not let it be an ordinary peer user? The main one already is, UIAM.
Why couldn't it protect /gnu/ storage as a user which the kernel can
keep others from writing to in the usual way?

Another option for managing storage and quickly switching access might be
if you trust the wayland daemons and their protocol for managing a single
user thread's buffers. You might be able to use its event loop to schedule
multiplexed concurrent build jobs.

A peer user daemon scenario might also open possibilities for networked
job distribution beyond a local router's connections, I imagine?
--
Regards,
Bengt Richter