Hi Liliana, I’m relatively new to Guix. But I’ve been converting my Emacs configuration to use Guix with native compilation recently, so I think have a basic understanding of this patchset. It seems like getting binary substitutes for more Emacs variants shouldn’t require quadrupling the number of top-level Emacs packages in Guix. I assume you used some degree of automation to generate these, but it seems like a bit of a pain to maintain, no? I guess you could implement some sort of CI checking if patches for new packages include the correct variants, but it still seems like it will lead to an increase in review burden. Seems too easy to make typos with the variant prefix, for example. Plus there are UX issues for end users, like a quadrupling in noise from ‘guix search emacs ’. It seems like there must be a way to indicate to Cuirass to build a set of packages with rewritten inputs, /without/ exposing those packages directly. I believe Nix does something like this by providing an ‘emacsPackagesFor’ function that provides an ergonomic way for users to target an Emacs variant. See Example 6 in [Adding Packages to Emacs — NixOS Manual]. Right now, Guix users have to use something like ‘package-input-rewriting’ directly and figure out the list of Emacs variants to override to their Emacs package, since not all packages use `emacs-minimal'. For binary substitutes, the community emacs-overlay project [tells Hydra to build] the set of Emacs packages with each common Emacs variant. We currently don’t have a well-defined “package set” for Emacs packages to map rewrites over like Nix, and I don’t know if that is ultimately the right solution, but I really don’t think we should approach this by adding so many trivial packages to the top-level package set. Imagine if we took this approach Guix-wide for supporting another libc, for example. Hope I didn’t misunderstand anything too much. Thanks, —Liam [Adding Packages to Emacs — NixOS Manual] [tells Hydra to build]