Hello Leo! > This is not as much a guix package vs. guix system issue as it is an > issue of explicit manifests against implicit ones. If you use guix > package with manifests and without inferiors, you will have the same > problem. Likewise, you can use inferiors in your config.scm to > mitigate some of those issues. At least it works for the kernel, but > it should in theory also work for packages.
I see. > PS: What you're envisioning is probably a front-end, that obscures the > very existence of a config.scm by managing one that is just as verbose > as guix-generated manifests are. However, this is not really a > solution as it fails to address the need for a (human-readable) initial > configuration. The interface would also be a pain to deal with as each > service comes with its own configuration record allowing arbitrary lisp > expressions that one would have to write on the command line. I think we can still maintain the guix way of doing config.scm and also bring modularity. My thought is, what if we could split the operating-system procedures into smaller procedures, such as, kernel, system-wide packages, services etc. into separate procedures? So if a user passes the procedure name to the `guix system reconfigure` command, then only that procedure is reconfigured. For example, we can reconfigure kernel of the system without reconfiguring packages and services. What do you think? Regards, RG.