Thoughts on making Guix even better

[Leo Prikler <leo.prikler@student.tugraz.at>]

Hello Raghav!
> Lets assume we have 5 packages in profile. Package 1, 3 and 5 has
> non-critical 
> updates. Package 4 has non-critical update but it breaks. Package 2
> has 
> critical update (CVE). We can either upgrade all packages except
> package 4 (or) 
> we can upgrade only package 2.
> 
> Lets assume we have 5 services/packages in system. Package/Service 1,
> 3 and 5 
> has non-critical updates. Package/Service 4 has non-critical update
> but it 
> breaks. Package/Service 2 has critical update (CVE). Now, when we
> reconfigure 
> the system, all packages/services will upgrade, package/service 4
> will break 
> the system. We can of course do '--roll-back' and take the system to
> previous 
> working state. But that will leave the system with critical
> vulnerability. 
> Therefore, we cannot reconfigure package/service 2 or any other parts
> of the 
> system, until the package/service 4 is fixed. This window/gap puts
> guix system 
> at great risk and instability.
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.

The problem with inferiors as a solution to this problem is, that it
doesn't address the issues of services.  You'd have to use the current
service structure with an inferior-package, which is not always what
you want, specifically when the introduction of a new field to that
service causes an issue.  In addition to that, finding all package
references and patching them to not include some breaking package (say
e.g. the newest mesa version, which depending on your graphics card may
or may not cause issues) can be very tedious depending on what is
referenced where.  Perhaps a lookup-inferior-services procedure might
help here.  

Overall, there are also some "not so fun" things when dealing with
inferior packages.  For one (car (lookup-inferior-packages ...)) is
quite a mouthful, especially when you know you'll always want the first
result or there is only one to begin with.  I'd welcome a procedure to
turn an inferior into a procedure that always returns the first match. 
IIRC inferior packages are also not always accepted as packages, but
I'd welcome being proven wrong about that.

You can also modularize guix system by wrapping each and every service
in a module which you either re-export from guix proper or -- in case
of some failure -- implement on your own.  That's a lot of work
however.

TL;DR: You can "modularize" transactions with 'guix system' in the same
way you modularize 'guix package -m' (the "-m" means "not modular" ;P).
 
Regards,
Leo

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.