Naranden writes: > On 5/16/25 04:14, James Thomas wrote: >> Naranden writes: >>> On 5/11/25 00:03, Naranden wrote: >>>> I am wondering about writing various >>>> container operating-system definitions, adding those as services to a >>>> host operating-system definition, and then using guix deploy to deploy >>>> the host operating-system. >>> >>> In case anyone is interested, I was able to get something *like* this to >>> work with Docker containers: I can define an operating-system that is >>> then included as a service in a parent operating-system. >> >> FYI: rootless-podman might be better. > > I agree, but the integrated OCI service that accepts an operating-system > definition (through oci-image) does not (yet) support Podman (the > <https://issues.guix.gnu.org/76081> "OCI provisioning service" patches > may change that).
Oh, sorry. > Also the basic rootless Podman service is not working. (Running `podman` > as root: "Failed to obtain podman configuration: runroot must be set". > As user: "Failed to obtain podman configuration: mkdir > /run/user/0/libpod: permission denied".) Can't speak about this particular error, but I'd had it working. >>> With Docker involved here, there is extra time and disk space used >>> bundling and extracting the OCI image. Guix bundles the operating-system >>> into an image.tar.gz and then the parent operating-system tells Docker >>> to load that image from the store. >>> >>> I suppose there must be some way to make this work like Guix system >>> containers, where everything the container needs is loaded from the >>> store rather than through Docker. >> >> Why not build the 'container' script for the users and let them run it? > > I'm not sure what you mean. The goal isn't to ship to other users but > to declare a specific, reproducible operating-system with services > that can be deployed on a local (real) system, in a VM, or remotely. > More specifically, the goal is to include a guix system container > service in an operating-system definition--in other words, > a Guix operating-system (container) nested in another operating-system > (parent). That's what running the script of ‘container’ in (info "(guix) Invoking guix system") gets you, no? No new 'service' should be required. > I was able to make that work that with Docker as described in my > previous message. Making it work with Podman would be better. But in > both cases, many of the advantages of using Guix end at the point of > producing the OCI image (because it is essentially an export from Guix). > Making it work with Guix with be a lot better--all the Guix machinery > would work end-to-end. > > There are three other related questions that might be good to include > here as further explanation: > > 1. I can bundle a package (and its dependencies) and run a command in a > container with `guix shell --container $package -- run`. Can I set up > the same thing to happen as a Shepherd-managed service (in an > operating-system definition)? > > 2. And if that can be done, can I set the channels and use package > inferiors so I would get the equivalent of `guix time-machine -C > $channels -- shell ...` but in a Shepherd-managed service as in (1)? > > 3. And if *that* can be done, can I do the same with an entire nested > operating-system as in my original question and example?! That is, > equivalent to `guix time-machine -C $channels -- system vm $file` but as > a Shepherd-managed service nested inside a parent operating-system > definition, where the parent operating-system definition could itself be > executed in a VM with `guix time-machine -C $channels -- system vm > $file`. (It's amazing that this level of reproducibility might actually > be possible with Guix.) AFAIU your requirements, they're possible with the shepherd-transient service and 'guix time-machine' prefixing the command mentioned above. --