Installing some packages results in "incomplete deployment"

Installing some packages results in "incomplete deployment"

[Chris Marusich]

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

Re: Installing some packages results in "incomplete deployment"

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 4068 bytes --]

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 <cmmarusich@gmail.com>:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4914 bytes --]

Re: Installing some packages results in "incomplete deployment"

[Adam Van Ymeren]

On December 2, 2017 4:50:04 AM EST, Chris Marusich <cmmarusich@gmail.com> wrote:
>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.

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.

Re: Installing some packages results in "incomplete deployment"

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

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...


2017-12-02 18:27 GMT+01:00 Adam Van Ymeren <adam@vany.ca>:

> On December 2, 2017 4:50:04 AM EST, Chris Marusich <cmmarusich@gmail.com>
> wrote:
> >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.
>
> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

Re: Installing some packages results in "incomplete deployment"

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> 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?

[...]

> * 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’.

Re: Installing some packages results in "incomplete deployment"

[Ricardo Wurmus]

Hi Ludo,

> 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?

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