>jeu. 05 févr. 2026 at 23:10, Simon Josefsson <[email protected]> wrote:
> Cayetano Santos <[email protected]> writes: > >> SourceHut side, these are not OCI container images. They run a daily >> cron job. Starting from the previous image, they build a new one, >> replacing it. >> >> I like this way of doing things, as this produces an always up to date >> image (with its drawbacks). As you can see, this process might break >> from time to time, but is not frequent >> >> https://builds.sr.ht/~sircmpwn/refresh/guix >> >> The scripts are rather simple: >> >> https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/images/guix > > Let me see if I understand: > > 1) These are full-blown 'guix system' images? How large are they? As > far as I recall, 'guix system' images are not suitable for container > environments, or are there exceptions? Are your images more like 'cloud > images' than 'container images' perhaps? I see you use qcow2. Would > they work in a 'libvirt' environment? I really want that too, but it is > different from container images. One can reproduce the image locally, to play with it. Now, the real question is, where exactly is it going to be deployed ? No matter what my hardware is, I need to produce an image adapted to the running ci facility: it happened that , in one of Guix’s commits, we introduced an incompatibility between our qemu, and the older qemu running the image, which broke it up. Manual intervention was required at this point. Which is a lesson to learn: check your image before releasing in production (sr.ht doesn’t). > 3) This is effectively doing a iterative 'guix pull && guix system > reconfigure' to update itself? Exactly, just simply. Except the update here is a complete replacement. > How was the first image bootstrapped? Good question ! I’m not at the origin of it all, previous image maintainer should know. They probably just push it from a local build. > My images are built from Debian containers, and I would like to avoid > that and just built them from the previous pure Guix container itself. > But I don't want to lose the bootstrapping ability, which feels > important. Maybe building once from pure Guix and once bootstrapped > from Debian+Guix and test for reproducibility would help. Perhaps this > aspect is not worth keeping in any official Guix images, I doubt you > want to run anything Debian as part of that? This is another interesting question, provided you get a recurrent fresh image, and the way Guix works, does it matter how exactly did you bootstrap its origins ? I have to admit I don’t see the need for it, in my use case: no matter the way you bootstrap your image, it is expected to be bit identical, to my understanding, which is what really matters. Am I missing something here ? C.
signature.asc
Description: PGP signature
