Hi Rutherther !
Thank you for the explanation. I think there's an optimization to be made where we use only the history from the currently installed version on, not the full history, and then remove previous commits after an update. Kind of like pruning nodes do on the various blockchains. Implementing this securely would require months of work, so I can't launch myself into it right now, but I'll keep it in mind. Thanks also for your blog post ! Your implementation is extremely clean and integrates perfectly in a guix system. What licence is your code under ? Do you mind if I add this service to my channel ? I would like to tweak it just a little bit: #+begin_src sh mount -t overlay overlay -o \ lowerdir="/root/.cache/guix",\ upperdir="/home/$user/.cache/guix-overlay",\ workdir="/home/$user/.cache/guix-workdir" \ "/home/$user/.cache/guix" bindfs --mirror=$user /home/$user/.cache/guix /home/$user/.cache/guix #+end_src this is what I came up with last time I had a problem with the cache https://the-dam.org/docs/explanations/GarbageCollection.html It solves the problem of users involuntary stepping on each others' toes, as well as the security issue of a user poisoning another's cache. The way it works is it overlays a user-writable dir over root's cache, and uses bindfs to make the system believe this fully owned by the user. By combining your service and this script I think we can have the best of both worlds :) Thank you for your help ! Edouard. Rutherther <[email protected]> writes: > Hello Edouard, > > On June 14, 2025 11:23:33 AM GMT+02:00, Edouard Klein <[email protected]> wrote: >>Hi ! >> >>I'm trying to let users reconfigure their home configuration on a shared >>guix system, but we can't all have a 700MB .cache/guix dir. I've solved >>part of the problem by forbidding guix pull and deploying an up-to-date >>system wide guix regularly. >> >>However, when running guix home reconfigure config.scm, with config.scm >>containing the most empty home configuration in the history of empty >>home configurations: >> >>#+begin_src scheme >>(use-modules (beaver home) >> (gnu home)) >> >>(-> (home-environment >> (packages '()) >> (essential-services '()) >> (services '()) >> (location #f))) >>#+end_src >> >>guix dutifully pulls the whole guix repo into the cache :/ >> >>I know there is a system service I can use to deploy the home >>configuration too, but this makes us lose the flexibility of having a >>user-configurable home. >> >>I think I'll maintain a systemwide cache as a workaround, but any >>guidance as to why guix home needs a full copy of the whole history of >>guix would help me understand how to get rid of that. >> > > Both guix home and guix system reconfigure need this to be able to check if > the > update you are making is a forward update, and to forbid a backward one by > default. You can allow it by --allow-downgrades, but you will still get a > warning and to get that, the repo has to be pulled, fully. Then it is checked > if > the current guix commit used for reconfigure is descendant of the previous one > used for reconfigure. > > There is no way to disable this currently without modifying guix source > itself. > > I came up with an idea on how to share the checkouts between multiple users > using bind mounts, see > <https://ruther.ditigal.xyz/posts/shared-guix-checkout/>. > The only downside is that users could potentially corrupt the cache for other > if > they were bad actors. > > Rutherther > >> >>Thanks in advance. >> >>Edouard.
