On Tue, Jan 13 2026, Giacomo Leidi wrote: > Hi Kristoffer, > > On 1/13/26 09:06, Kristoffer Balintona wrote: >> AFAIU this is basically how container image upgrading in Guix is for >> now, barring OCI images packaged by Guile/Guix itself. It seems >> non-declarative and non-ideal for Guix though, so I wonder if there >> could theoretically (i.e., sometime in the future if someone cares >> enough and has the time and expertise) be a more Guix-y solution. >> Something that can update non-Guix images while retaining Guix's goal of >> reproducibility. > > I'm not sure I completely understand your point, so it depends on what > your expectations are but I agree this can be improved. The way I use > OCI services is to never track the latest tag, only and always to track > known versions. This way each upgrade is predictable. What would you > expect from a Guix-y upgrade mechanism?
What I mean is having the images themselves within the store such that images are a part of roll backs and are upgraded with the rest of the system. For instance, a user can define their own `oci-image', letting the images be upgraded and rolled back as part of a transaction within the Guix system. This can already be done for user-defined images in guile, but not for premade images from e.g. Docker Hub, where one has to upgrade/pull and roll back image versions in a way separate from Guix (with those images not being kept in the store either). I am somewhat new to Guix so feel free to correct me. -- Kind regards, Kristoffer
