Re: Installing some packages results in "incomplete deployment"

[Gábor Boskovits]

I agree with this.

I would add a few more to the list of states I would like to see managed in some standard way.

One of these is hardware state, for example do some automated action if a raid array degrades, or a disk removed/added...

Another on that would be great to have is some way to manage secrets.

Some service configuration files for example might store passwords, storing these in the store, where everything is readable is not wise.

Service configurations might store other informations, which in some setups might be confdiental, on others not. For example hostnames, ports, security configuration settings.

It would be great if we had at least a general recommendation how these should be done.

I think guix have a really good place in the infrastructure layer, once we have a few problems resolved.

I've also seen some news about guix-deploy, which would be very good to have, but I'm not sure about current status.

2017-12-02 10:50 GMT+01:00 Chris Marusich <address@hidden>:

Hi,

Some Guix packages exist which are not intended to be installed into a
user's profile.  For example, android-udev-rules's description says:

    _Simply installing this package will not have any effect._ It is
    meant to be passed to the `udev' service.

Still other packages do not work if they are installed by themselves.
For example, xscreensaver (and other screen lockers [1]) does not work
if you just install it into your profile; you need to add an instance of
the screen-locker-service-type to your operating system declaration to
ensure that xscreensaver gets installed as a setuid-root program.  Even
after you do this, to be able to configure xscreensaver using the
xscreensaver-demo program, you ALSO need to remember to install
xscreensaver either into the system profile or into your user profile.

Is there anything we can do about this situation?  One of the benefits
of the purely functional software deployment model is that it can be
used to guarantee complete deployment (i.e., no missing dependencies).
However, in this case, installing packages like android-udev-rules or
xscreensaver by themselves will result in incomplete deployment.

Can we do better?  There is a lot of state that exists outside of the
store which cannot be managed using the purely functional software
deployment model alone.  For example, the bootloader is one of these
things.  Whether or not your SSH daemon is currently running is another
piece of state that falls into this category.  The database of a MySQL
server is another.  And so on.

To the extent that this kind of system state exists outside of the the
functional software deployment model, I think it's probably fair to ask
users to manage it themselves.  In the case of xscreensaver, this means
that it's probably reasonable to ask a user to remember to take two
separate actions (reconfigure the system with a screen locker service
that uses xscreensaver, and also install the xscreensaver into a
profile).  However, I still think there are some things we might be able
to do to reduce confusion and make it harder to make mistakes.  Here are
some ideas:

* Document packages like these - like android-udev-rules already does.

* Don't display these packages by default in tools like "guix package
  --search" (but maybe provide an option for displaying them if needed).

* Don't export packages like these as public variables - hide them in
  appropriate services.  For example, instead of requiring a user to
  install both a service of the screen-locker-service-type configured to
  use xscreensaver and also the xscreensaver package, modify the
  screen-locker-service-type so that it automatically installs the
  package into the system profile by extending the profile-service-type.
  In short, make it impossible to install an xscreensaver screen locker
  service incorrectly.

What do you think?

Footnotes:
[1]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27083

--
Chris