Re: The tricky case of "--localstatedir=/var"

[Ricardo Wurmus]

Jookia <address@hidden> writes:

> Hey there,
>
> Over the past month a few people (myself included) have been hit by the 
> 'gotcha'
> of not running ./configure with "--localstatedir=/var". It doesn't say this in
> the documentation but I question whether not having it as /var is a sane
> default. I'm sure this is somehow tied to the conventions of /usr/local.
> Here's how this issue could be fixed, in order of usefulness:
>
> * Change localstatedir to /var by default.
>
> This makes a lot of sense considering that's where it's expected to be. Even
> patches within Guix assume it's in /var , so installing and building Guix
> without localstatedir in /var would not only be a weird idea, it will actually
> *break* things. See avahi, xorg-server, findutils.

I like this because I assume most people really don’t want to have
localstatedir somewhere in /usr/local.

> * Put the localstatedir in /gnu.
>
> This is actually what Nix does, so I'm a little surprised as to why Guix has
> deviated from this practice. This will require updating all the patches to use
> /gnu/var as the localstatedir. What you get from this is the idea that the 
> state
> is linked with the store (which it is!) and more importantly, comes in to the
> territory of GNU.

I’m actually doing this on my cluster installation.  It’s very
convenient at first because you can just mount /gnu and be done with it,
but since enabling users to manage their profiles from all cluster nodes
over the network “/gnu” and “/gnu/var” have to be mounted separately and
sequentially with different flags: “/gnu” should be read-only in general
(in particular “/gnu/store”) and “/gnu/var/guix/profiles” must be
read-writeable for users to be able to install things into their
profiles.

One thing that doesn’t work out of the box is users installing guix with
guix, because that’s preconfigured for a localstatedir in “/var”.  (The
easy fix is to overwrite the guix package definition.)

> * Instruct people to always pass "--localstatedir=/var" to configure.
>
> Sure, this could be done. But people are going to forget to do this and we'll
> have to explain on IRC to read the manual, then have them need to redo their
> entire Guix setup once they find something broken. Manually moving the state
> directory around is fragile enough since it involves moving symlinks around 
> for
> profiles and isn't easily explained to people.
>
> More importantly, people are going to come away from their Guix experience 
> with
> the feeling that something easily avoided has cost them a lot of their time, 
> and
> they'd be right.

I think we already have too many steps to set up Guix.  Having one fewer
flag to understand and pay attention to would be an improvement.  We can
mention the “localstatedir” flag (and its default value) in the manual,
but I’d like to cast my vote for one of the two previous suggestions.

> The advantage this approach has is that localstatedir is configurable.
> Unfortunately, packages will still be broken. Perhaps it's time to substitute
> patch files too and introduce localstatedir as a build variable.

Is this really so?  Could you give us an example please?

> * Do nothing.
>
> Software will still be confusing and debatedly broken. No doubt people will be
> having this discussion again.

Agreed.

~~ Ricardo