Discussion:
Installing some packages results in "incomplete deployment"
(too old to reply)
Chris Marusich
2017-12-02 09:50:04 UTC
Permalink
Raw Message
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
Gábor Boskovits
2017-12-02 10:03:21 UTC
Permalink
Raw Message
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.
Post by Chris Marusich
Hi,
Some Guix packages exist which are not intended to be installed into a
_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
* 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?
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27083
--
Chris
Adam Van Ymeren
2017-12-02 17:27:25 UTC
Permalink
Raw Message
Post by Chris Marusich
Hi,
Some Guix packages exist which are not intended to be installed into a
_Simply installing this package will not have any effect._ It is
meant to be passed to the `udev' service.
I think that for packages which are not meant to be installed into a user profile, guix package -i should refuse to install them, or maybe only install them with a --force flag or similar.

If it doesn't make sense to install a package into my profile it'd be nice if the tools prevented it by default.
Gábor Boskovits
2017-12-02 17:51:36 UTC
Permalink
Raw Message
I agree with that.
It would however mean additional metadata on the packages.
If there is consent, that this is a good idea, we could find out what
additional information is needed, and how to integrate that.
It could be done like test, or strip-binaries...
Then if we have the current behaviour as default, then only the packages
which should not be installed should be modified...
Post by Adam Van Ymeren
Post by Chris Marusich
Hi,
Some Guix packages exist which are not intended to be installed into a
_Simply installing this package will not have any effect._ It is
meant to be passed to the `udev' service.
I think that for packages which are not meant to be installed into a user
profile, guix package -i should refuse to install them, or maybe only
install them with a --force flag or similar.
If it doesn't make sense to install a package into my profile it'd be nice
if the tools prevented it by default.
Ludovic Courtès
2017-12-04 09:18:41 UTC
Permalink
Raw Message
Hi Chris,
Post by Chris Marusich
Some Guix packages exist which are not intended to be installed into a
_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?
[...]
Post by Chris Marusich
* 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?
I think adding a line in descriptions is often not very helpful—few
people are going to read that line.

Hiding those packages from the UI would be trivial: see ‘hidden-package’
in (guix packages).

We could do that, but it might be confusing: people will have a hard
time finding which screensavers are available, which is problematic.

Perhaps we could offer an option for packages to display hints at
installation time. Like

(package
(name "xscreensaver")
;; …
(properties
`((installation-notice
. ,(G_ "Please see the documentation of
@code{screen-locker-service-type} in the manual on how to use this
screen saver.")))))

Or maybe something higher level, like:

'((use-with-service . screen-locker-service-type))

Thoughts?

Ludo’.
Ricardo Wurmus
2017-12-07 15:37:21 UTC
Permalink
Raw Message
Hi Ludo,
Post by Ludovic Courtès
Perhaps we could offer an option for packages to display hints at
installation time. Like
(package
(name "xscreensaver")
;; …
(properties
`((installation-notice
. ,(G_ "Please see the documentation of
@code{screen-locker-service-type} in the manual on how to use this
screen saver.")))))
'((use-with-service . screen-locker-service-type))
Thoughts?
I like the higher-level approach. We can use this in a future system
configuration interface (e.g. to display available service extensions)
as well as on the command line by displaying hints like the above.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net

Loading...