Re: Building, packaging and updating Guix with confidence

[Zhu Zihao <all_but_last@163.com>]

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]


Josselin Poiret <dev@jpoiret.xyz> writes:

> In the second case, I am in the process of adding a very simple Guile C
> extension to Guix that only requires to wrap a simple libc function.
> The C code itself took approx. 5% of my time on it, while adding the
> magical invocations for the Autotools took 35%, and now testing the
> changes is taking 60%,

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

> because I need to test that `guix pull` works,
> that the local development setup works, and that the guix package works,
> all with a local change that cannot be authenticated and that also
> cannot be referred to with a git-reference [more on that later] since
> it's entirely local.  This is causing me many headaches, and I don't
> think that even after manually testing this with handwritten hacks so
> that these changes actually do appear everywhere, I will be confident
> enough for them to be merged.

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

```
cat > local-channel.scm << "EOF"
(list (channel
       (inherit %default-guix-channel)
       (url "/home/foo/bar/path/to/local/guix/repo")
       (branch "test-branch")))
EOF       

guix time-machine -C local-channels.scm --disable-authentication -- build hello
```

> c) The `guix pull` way.  This is a bit of an hybrid.  Internally, it
> amounts to eval'ing build-aux/build-self.scm inside of the currently
> running guix, which returns a procedure which, given a source code
> checkout of Guix, returns a derivation that builds the new Guix.  This
> itself relies on (guix self) where most of the building code is.  The
> scheme modules are compiled in an ad-hoc manner (not following
> Makefile.am), and files are included without consulting the Makefile.
> This is why `guix pull` users are not affected by [1].  But then, there
> still is an issue with the guix daemon (and in the future the C
> extensions), which is C code.  Since we're not pretending to know how to
> universally configure C packages, we rely on the guix-daemon package
> defined in gnu/packages/package-management.scm of the future Guix, which
> inherits from the guix package itself, and then builds itself roughly
> following b), meaning the daemon is still out-of-date.

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.

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

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]