Anybody doing it? I am talking about using guix for installing packages on a debian-12, whonix-17, etc qube (appVM). The discussion on the forum so far seems to have been around using guix inside standaloneVMs.
As far as I understand from watching a few guix package manager videos on youtube, guix creates a directory under /gnu/store/. Since this is outside the /home/user/ directory, I am assuming that this is a problem for using guix as a package manager inside a qube.
Any comments?
This can be useful in getting the guix dirs persistent in qubes
http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/doc/bind-dirs/
Long story short, since it seems like guix package manager writes to /gnu/store/ directory, in normal qubes, the changes in there don’t survive a reboot. But, turning that dir in a bind-dir seems to make it survive a reboot, and enable using guix inside a qube.
Also related topics:
It should works exactly like for Nix, except the path is /gnu/ instead of /nix/.
Guix is an old fork of Nix, but they maintained the architecture.
You might also want to look into the guix pack command. The --relocatable flag will let you install Guix packages to your home directory (though I’m not sure if substitutes will work with this). -f squashfs will save the packages to a disk image and you should be able to automatically mount it in your /rw/config/rc.local (in theory, I haven’t tested this).
necroing this thread. I am looking specifically for using guix package manager that I install from debian-12 apt repos for the purpose of deterministically compiling monero binaries from the monero source code.
Afaik, guix uses /gnu/store directory to store packages, etc., which is not feasible to use in an appVM (aka, qube). I don’t want to use guix package manager in my debian templates either (I don’t want the changes done by guix to propagate to other qubes, nor do I want to add one more template to my templates).
Anybody have any ideas? With flatpak, for example, I can use flatpak --user install to install the packages to my /home/user/ directory, and confine its efects to a single qube of mine. I wish guix package manager also allowed something similar.
You can use bind-dirs like I explained for nix (which uses /nix/store) Solene'% : How to install Nix in a Qubes OS AppVM
Hi,
FWIW, some time ago I played around Guix package management inside a Fedora template and this is my current setup yet. I have Guix (daemon) installed in TemplateVM and its packages persisted in AppVMs via bind-dirs. I wrote the steps in my blog for reference Guix/Nix in a Fedora Minimal TemplateVM
However I don’t recommend since bind-dirs in whole Guix store puts all the persistence to AppVMs, making disk usage get very high across multiple AppVMs, and it also loses the advantages of TemplateVMs (reuse the setup without letting AppVMs mutate the packages). I’m still playing around to realize the ideal setup for Guix in QubesOS, but I think its packages should persist in TemplateVM.
I am Guix-curious but I don’t know how Guix’s system design works with
QubesOS’ template-vs-appvm design.
I played only with Guix foreign, so the data is stored in the system it was installed. In my case, installed in a Fedora TemplateVM.
Because I wanted to install packages from AppVM, I used bind-dirs to persist Guix dirs.
I think an better scenario for Guix in Qubes would replicate Qubes intended flow:
dnf, apt, etc).Guix can replace dnf and apt in TemplateVM with ordinary guix install calls, but since Guix is intended to build declarative systems, and I think some of Guix features/design won’t apply.
I’m interested in using Guix declarative definition to declare workspaces to can be used in non-Qubes OSes as well (ie, GuixOS), but still figuring out. My next try would be having Guix foreign in a TemplateVM without bind-dirs in AppVM, and apply the system setup from the AppVM. If this work well the next step can be the integration with Qubes Updater.
I played only with Guix foreign, so the data is stored in the system
it was installed. In my case, installed in a Fedora TemplateVM.
Because I wanted to install packages from AppVM, I usedbind-dirsto
persist Guix dirs.
Yes, that’s how I am modeling in my mind, how I would use Guix package
manager on a debian qube, as well.
Does this mean, whatever Guix packages you install on the AppVM get
persistence on the TemplateVM, and therefore will be reflected on the
other AppVMs that share this same TemplateVM?
I think an better scenario for Guix in Qubes would replicate Qubes
intended flow:
- TemplateVM holds the binaries. In Qubes, intended to be installed
using distro’s package manager (dnf,apt, etc).- AppVM uses the binaries without persistence, persisting only user
data/config.
Yes, that would be better. Can you instruct Guix package manager to use
someplace in /home/user/ instead of the /gnu/store/? That way, we
could get AppVM-based persistence, without
reflecting/mirroring/persisting back the AppVM’s changes to the
TemplateVM.
[… 7 lines elided]
My next try would be having Guix foreign in a TemplateVM without
bind-dirsin AppVM, and apply the system setup from the AppVM.
Let me know in this thread how this goes.
Hello, sorry the delay (was migrating to 4.3.1 :))
No, the approach I don’t recommend using bind-dirs which I used in my previous setup was: Each AppVM has its own /gnu/store, no contamination. bind-dirs basically configures a path that AppVM can persist, but it’s not shared to anything else.
This is not optimal because one of the main goals of TemplateVMs is provide the binaries for the AppVMs based on it.
The bind-dirs setup works exactly this way (however store remains in default path). The link I provided instructs this approach, you’ll have a /gnu/store for each AppVM, however the AppVM disk usage will be high (all binaries from Guix will be stored on it) and TemplateVM wouldn’t provide the Guix packages, as now AppVM would have its own store. This is what bind-dirs does.
By design QubesOS doesn’t lets AppVM contaminate the TemplateVM, so it’s not possible for a change in AppVM reflect to another AppVMs.
In my recent Qubes upgrade I did a migration from scratch and this setup is way better. Now I have:
guix install or guix shell at TemplateVM to fetch the package./gnu/store is ephemeral for AppVMs (installed packages on it is lost at reboot)
It means that all packages from TemplateVM are inherited by all AppVMs based on it, which is fine. If I want a AppVM having a different set of packages (ie, have no browser ever fetched), I can setup a different TemplateVM. I think this aligns well with Qubes original design.
My next steps will be migrate my chezmoi setup to Guix home for AppVM management. This would take me some time and chezmoi is working great, but my final goal is have a full IaC concentrating in Guix so I can replicate in a GuixOS and Qubes management via SaltStack. Still learning though.