Ludovic Courtès <[email protected]> writes: >> 2) I'm not that familiar with the Guix project build system, but I >> suppose the images should be built by centralized by it? Is this >> feasible? What would be involved in making that happen? > > 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. >> 4) Decide on the set of variants to support. As a strawman my images >> are built using: >> >> guix pack $GUIX_PACKS --save-provenance -S /bin=bin -S /share=share >> -f docker --image-tag=guix --max-layers=8 ${GUIX_PACK_EXTRA:-} > > [...] > >> GUIX_PACKS_LATEST: $GUIX_PACKS_SLIM git-minimal findutils diffutils >> gcc-toolchain make automake autoconf tar grep sed gawk m4 gzip xz >> bzip2 iproute2 inetutils libcap shadow wget lndir nss-certs > > I’d do something like that. Do you have an opinion on if there should be only one container image variant, or multiple variants? Having just one variant feels simpler, but it will be unpractical. 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. >> 5) Decide if images should have non-/bin/sh entrypoint like MetaCall >> Guix Containers which sets up guix-daemon.sh etc. Sometimes you would >> want this, I guess, and sometimes you wouldn't, I guess. Maybe there is >> some idiom (environment variables?) to use for deciding? There could be >> different container names for different setups. > > 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. I think my concern is not so much having guix-daemon running but all the requirements needed for it to work: a populated /etc with /etc/passwd and /etc/group, the right guix-daemon user and build groups, netbase for port definitions, nss-certs for CA certs, working DNS name resolution, substituion servers authorized, and maybe some things I forgot. I find minimal images that doesn't come with all that extra stuff useful. This argues for having multiple official container variants for different audiences. >> 6) It would be useful to publish images for a recent 'master' commit but >> also for the Guix v1.5.0 release commit -- which ought to be forever >> bit-by-bit identical once prepared (or?) -- and for future releases. > > I suppose we could start by setting it up on ci.guix and in the next > release it would become and official artifact? Yay! >> 7) How are they distributed? I suppose the images could be published on >> gnu.org/gnu/guix/ but the container-way is via some public container >> registry. Docker Hub is well-known, but there are many other. I'm not >> sure if Codeberg offers one. What are the concerns here? > > If ci.guix is set up to build it, it will be downloadable there, but I > guess we should also upload it to some registry. No idea which one to > use though; these commercial things don’t look attractive to me. :-) 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? /Simon
signature.asc
Description: PGP signature
