Simon Josefsson <[email protected]> skribis: > Ludovic Courtès <[email protected]> writes:
[...] >> To be checked with the release team, but I would add it to >> ‘etc/teams/release/artifacts-manifest.scm’ so it’s built from ci.guix. > > Is that file the starting point to eventually add something to the main > download https://guix.gnu.org/sv/download/ page? I don't understand how > it all fits together. The manifest above is built here: https://ci.guix.gnu.org/jobset/release-artifacts We could add a link to the latest image from <https://guix.gnu.org/download/latest/>, similar to the other links on that page. (Although the better option from a usability viewpoint would be to upload those images to a registry since that’s what Docker/podman users expect.) > My preference is to have a couple of variants catered towards different > use-cases: > > 1) One "slim" variant being the most minimal image we know how to make > that still provides a POSIX /bin/sh environment and some way to run > 'guix install FOO' to install other tools. > > 2) One "latest" (which is an odd keyword but popular idiom in the > container world meaning "latest stable") that also contain GCC and tools > like the above, to provide an original Unix feeling. > > 3) Maybe a "extra" package with TexLive, python, perl etc is not that > critical to publish, although I find for GitLab CI/CD usage having a > more "fat" image will speed things up. > > 4) An experimental "gash" image with only 'guix gash gash-utils' for an > all-Guile Unix feeling. While GNU CoreUtils is stable and preferrable, > it seems interesting to explore a future all-Guile Guix setup. > > 5) Having 'guix system' images as was suggested seems useful too, > although where to draw the line between "container images" and "cloud > images" seems challenging. Maybe we don't have to and just have a "Guix > Container/Cloud Images Team" or something. OK, I see. We could limit ourselves to (1) and (2), particularly if this is going to be built on ci.guix because that consumes quite a bit of space. >> For most cases I suppose you’d want guix-daemon to be up and running? > > But not always. I have some GitLab CI/CD runs which just need a Guix > environment with some pre-installed common tools to do useful work. OK. Then the “CI/CD” variant would have guix-daemon up and running, and other variants not necessarily so, I guess? (I think CI/CD should be our primary use case for those images.) > Having them generated from ci.guix would be good enough, and maybe some > 'Guix Container Team' could be responsible for pushing them further out > into common registries? Sure, sounds like a plan! Ludo’.
