Simon Tournier <[email protected]> writes: > Hi, > > On Fri, 06 Feb 2026 at 18:19, Simon Josefsson via "Development of GNU > Guix and the GNU System distribution." <[email protected]> wrote: > >>> Therefore, the question would become: Would these Docker images be >>> published using DockerHub? >> >> I don't see a reason why not. I'm not sure the Guix project wants to >> have a proper docker.com account, but individuals could set it up and >> push the images? Assuming they are reproducibly built, people have a >> way of verifying them by comparing hashes. > > Today, Guix isn’t 100% bit-to-bit reproducible, to my knowledge. That’s > another topic, IMHO. :-)
Is there any explanation or documentation on what the limits are? > Well, the question I’ve raised could be: Is publishing images on > DockerHub aligned with GNU FSDG? To me, such question falls into the > same category as producing GNU Emacs binaries for the Microsoft Windows > platform. So, to me, yes! All is fine. :-) > > I don’t see a reason why not, either. I just wanted to be sure by > asking explicitly. Yes, it would be nice to have discussion/consensus on this. There is some overlap between FSDG and https://www.gnu.org/software/repo-criteria.en.html and I'm not at all convinced DockerHub is particular aligned here. However, even if DockerHub is not aligned, I do still agree with your conclusion that publishing Guix containers through that channel is okay. It is way to reach people on that platform and get them into the Guix spirit of things. Much like GNU Emacs on Windows or any non-FSDG platform. Of course, we should publish them PRIMARILY on some other site first. This is just about publishing another copy of them. >>>> guix pack $GUIX_PACKS --save-provenance -S /bin=bin -S /share=share >>>> -f docker --image-tag=guix --max-layers=8 ${GUIX_PACK_EXTRA:-} >>> >>> On a side note, please consider: >>> >>> >>> https://hpc.guix.info/blog/2021/10/when-docker-images-become-fixed-point/ >>> >>> However, last time I’ve checked, the manifest cannot used too complex >>> transformations. Well, it’s not an issue. >> >> I think a manifest.scm is included in my images too, or is there >> anything more required? > > First, I wanted to point out that the manifest included with the option > ’--save-provenance’ does not always capture all the transformations for > generating package variants. > > Second, instead of comparing hashes as you suggest above, I would > suggest instead to compare the channels.scm and manifest.scm files > extracted from the image. Since the image might not be bit-to-bit > identical for various reasons, these two files seem a good proxy for > identifying (and challenging) what’s inside the image. I'm not familiar with such a comparison, but I think both kind of comparisons may be necessary. Simply comparing manifest.scm's assume that containers were not prepared maliciously, which I'm not sure we can assume. /Simon
signature.asc
Description: PGP signature
