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

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

[Jookia]

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.

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

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

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.

* Do nothing.

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

Cheers,
Jookia.

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

[Ricardo Wurmus]

Jookia <166291@gmail.com> 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

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

[Jookia]

On Tue, Feb 16, 2016 at 03:29:02PM +0100, Ricardo Wurmus wrote:
> Is this really so?  Could you give us an example please?

Oops! I was misreading the git log and patches. I'm wrong on this (happily, I
may add!) So no, there's no patches to change. This is strictly a Guix issue.

> ~~ Ricardo

Jookia.

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

[Andreas Enge]

On Tue, Feb 16, 2016 at 03:29:02PM +0100, Ricardo Wurmus wrote:
> Jookia <166291@gmail.com> writes:
> > * Change localstatedir to /var by default.
> > * Put the localstatedir in /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.

This is an interesting point; I would rather have been in favour of the
second solution, assuming that it would also simplify the binary installation
(everything is self-contained inside /gnu). Why do they need to be mounted
separately? Could /gnu not be mounted keeping the access rights of the
original file system?

There is also a middle ground that would be possible: Move some of the
content of localstatedir to /gnu; this would make sense for the sqlite
database, for instance. Then it would be possible to copy /gnu from one
system to another. On the other hand, there are quite a few more things
in /var/guix, so maybe this is not really sensible.

In any case, I am for implementing one of these two possibilities.

Andreas

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

[Jookia]

On Tue, Feb 16, 2016 at 05:41:09PM +0100, Andreas Enge wrote:
> There is also a middle ground that would be possible: Move some of the
> content of localstatedir to /gnu; this would make sense for the sqlite
> database, for instance. Then it would be possible to copy /gnu from one
> system to another. On the other hand, there are quite a few more things
> in /var/guix, so maybe this is not really sensible.

I'm not sure how that would really fix the issue that people are hitting: Say we
move some of the content to /gnu, things like profiles, the daemon socket, all
the things that Guix looks for and symlinks to won't be found if Guix looks in
/usr/local/var/guix and /gnu instead of /var/guix and /gnu.

> Andreas

Jookia.

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

[Andreas Enge]

On Wed, Feb 17, 2016 at 04:12:32AM +1100, Jookia wrote:
> I'm not sure how that would really fix the issue that people are hitting: Say we
> move some of the content to /gnu, things like profiles, the daemon socket, all
> the things that Guix looks for and symlinks to won't be found if Guix looks in
> /usr/local/var/guix and /gnu instead of /var/guix and /gnu.

I meant mixing both of your suggestions: move some of the data to /gnu,
and make /var the default for (the remaining) localstatedir.

Andreas

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

[Tobias Geerinckx-Rice]

Hullo Guix,

On 16 February 2016 at 14:57, Jookia <166291@gmail.com> wrote:
> <snip>
>
> * 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.

As a newcomer from a certain Nix-based OS, /var/gnu surprised me.
Store state and integrity are so closely tied to the sqlite database
that it's strange to see them so far apart. I assume there are other
reasons for using /var, and I assume these are reasons are logs.
(Disregarding FHS traditionalism as an option for everyone's sanity.)

I actually searched for a discussion about this in Guix's past, but
found none. I await the link of loving correction.

Kind regards,

T G-R

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

[Tobias Geerinckx-Rice]

On 16 February 2016 at 17:04, Tobias Geerinckx-Rice
<tobias.geerinckx.rice@gmail.com> wrote:
> Hullo Guix,
>
> On 16 February 2016 at 14:57, Jookia <166291@gmail.com> wrote:
>> <snip>
>>
>> * 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.
>
> As a newcomer from a certain Nix-based OS, /var/gnu surprised me.

s/gnu/guix/, of course. But even non-GuixSD systems have /gnu, so it
can't be for them.

> Store state and integrity are so closely tied to the sqlite database
> that it's strange to see them so far apart. I assume there are other
> reasons for using /var, and I assume these are reasons are logs.
> (Disregarding FHS traditionalism as an option for everyone's sanity.)
>
> I actually searched for a discussion about this in Guix's past, but
> found none. I await the link of loving correction.
>
> Kind regards,
>
> T G-R

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

[Christopher Allan Webber]

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

Just chiming into the chorus: this really confounded me.  I think the
breakdown here is a good one.  I'd love to see one of these approaches taken.

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

[Danny Milosavljevic]

Hi,

also, even worse, when using a fine git checkout for some time, you will from time to time do this:

$ git pull
$ make check

If this touches stuff autoconf cares about, make will do ./configure again and leave localstatedir off. Then lots (32) of the tests will fail.

Just happened again...

Regards,
   Danny

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

[Mark H Weaver]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> also, even worse, when using a fine git checkout for some time, you will from time to time do this:
>
> $ git pull
> $ make check
>
> If this touches stuff autoconf cares about, make will do ./configure
> again and leave localstatedir off. Then lots (32) of the tests will
> fail.

This shouldn't happen, the configure flags should be preserved.  It has
never happened to me, and I've been doing "git pull && make" regularly
for a couple of years now.

Can you email bug-guix@gnu.org about your experience here?

     Mark

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

[Ricardo Wurmus]

Mark H Weaver <mhw@netris.org> writes:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
>> also, even worse, when using a fine git checkout for some time, you will from time to time do this:
>>
>> $ git pull
>> $ make check
>>
>> If this touches stuff autoconf cares about, make will do ./configure
>> again and leave localstatedir off. Then lots (32) of the tests will
>> fail.
>
> This shouldn't happen, the configure flags should be preserved.  It has
> never happened to me, and I've been doing "git pull && make" regularly
> for a couple of years now.

I’m doing “git pull && make” regularly, too, and configure flags are
usually cached.  I don’t remember when I last had to reconfigure.

~~ Ricardo

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

[Chris Marusich]

Jookia <166291@gmail.com> writes:

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

I'm not sure there is a single default that will work for everybody. In
general, a value that is appropriate for one use case will not be
appropriate for a different use case.

For example, the README file in the root directory of Guix's git
repository [1] explains that if you want to re-build and re-install Guix
using a system that already runs Guix, it's important to explicitly set
the localstatedir variable to an appropriate value so that the new Guix
sees the existing items in the store. On GuixSD, I believe the
appropriate value would be "/var". Similarly, the Guix manual also
explains [2] that if you wish to have Guix and Nix share the same store,
you must explicitly set the localstatedir variable to an appropriate
value. According to the manual, if you're using Nix's defaults, then
that's "/nix/var". No single default value will satisfy both of those
use cases; somebody will always have to explicitly specify the
localstatedir.

Therefore, instead of worrying about what the "right" default should be,
perhaps it makes more sense to focus on how the documentation can be
improved. If setting the localstatedir is important, the manual should
explain that. The manual already mentions localstatedir, as shown above,
but perhaps the manual is not clear enough. People do seem to be
tripping over it.

With the aim of improving the documentation, then, I'll ask: what was
your use case? Why did you need to set the localstatedir explicitly? Is
there a place in the manual where, if information about the
localstatedir had been present, you would have realized from the start
that you needed to set it, and you would have understood what the
appropriate value to use was?

Best regards,
Chris

[1] README file: http://git.savannah.gnu.org/cgit/guix.git/tree/README
[2] Info node "(guix) Requirements": https://www.gnu.org/software/guix/manual/html_node/Requirements.html

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

[Jookia]

On Wed, Feb 17, 2016 at 12:06:25AM -0800, Chris Marusich wrote:
> I'm not sure there is a single default that will work for everybody. In
> general, a value that is appropriate for one use case will not be
> appropriate for a different use case.

I hope I'm not implying that a single default will work for everyone. The
problem is that the default value is incompatible with how you'd expect Guix to
work. More importantly, the Guix package doesn't use this default which breaks
compatibility with itself.

> For example, the README file in the root directory of Guix's git
> repository [1] explains that if you want to re-build and re-install Guix
> using a system that already runs Guix, it's important to explicitly set
> the localstatedir variable to an appropriate value so that the new Guix
> sees the existing items in the store. On GuixSD, I believe the
> appropriate value would be "/var". Similarly, the Guix manual also
> explains [2] that if you wish to have Guix and Nix share the same store,
> you must explicitly set the localstatedir variable to an appropriate
> value. According to the manual, if you're using Nix's defaults, then
> that's "/nix/var". No single default value will satisfy both of those
> use cases; somebody will always have to explicitly specify the
> localstatedir.

Reading the instructions in the README, they still wouldn't have been useful to
me as I wasn't running Guix in the first place, nor could I have found out the
correct value for localestatedir as I didn't have a currently installed Guix. I
wasn't getting Guix and Nix to share my store either, so I expected the defaults
to let me use Guix 'normally', as a package manager. It didn't do this.

I think there's a difference between having a default that works for a lot of
people and documenting alternate approaches like using /nix/var, and a default
that everyone has to change to get a self-hosting Guix system. The moment you
install Guix in Guix and try to use that, you hit big problems.

> Therefore, instead of worrying about what the "right" default should be,
> perhaps it makes more sense to focus on how the documentation can be
> improved. If setting the localstatedir is important, the manual should
> explain that. The manual already mentions localstatedir, as shown above,
> but perhaps the manual is not clear enough. People do seem to be
> tripping over it.

Setting the localstatedir is only important because if you don't set it, you're
incompatible with the rest of the Guix ecosystem as Guix itself doesn't use that
default. I really think it's a bad idea to add things to the documentation that
should almost always be the default.

> With the aim of improving the documentation, then, I'll ask: what was
> your use case? Why did you need to set the localstatedir explicitly? Is
> there a place in the manual where, if information about the
> localstatedir had been present, you would have realized from the start
> that you needed to set it, and you would have understood what the
> appropriate value to use was?

My use case is building Guix, then using the Guix package in Guix. This includes
doing things like 'guix package -i guix', 'guix environment guix', 'guix pull',
etc. These things are required for normal and encouraged use. The only time the
existing default would be helpful if you didn't do those things, meaning you
always used your own build of Guix outside of the store.

> Best regards,
> Chris

Cheers,
Jookia.

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

[Chris Marusich]

Jookia <166291@gmail.com> writes:

> the Guix package doesn't use this default which breaks compatibility
> with itself.

Ah, I see what you're saying. I think you're saying that the guix
package (defined in gnu/packages/package-management.scm) explicitly sets
the localstatedir to "/var", even though the default localstatedir used
in the guix build scripts winds up being "/usr/local/var", so it causes
problems. Is that right?

It looks like the decision to explicitly set localstatedir to "/var" in
the guix package was made in commit 2d195e67 by Ludo. Perhaps he can
explain what his intent was.

> My use case is building Guix, then using the Guix package in Guix. This includes
> doing things like 'guix package -i guix', 'guix environment guix', 'guix pull',
> etc. These things are required for normal and encouraged use. The only time the
> existing default would be helpful if you didn't do those things, meaning you
> always used your own build of Guix outside of the store.

I understand why you would want to do "guix environment guix" (e.g., to
get the dependencies for guix so you can build it), but I'm curious: why
would you want to do "guix package -i guix"? This is a bit of a
digression, but I'm curious to know why one might want do that.

- Chris

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

[Jookia]

On Wed, Feb 17, 2016 at 01:15:17AM -0800, Chris Marusich wrote:
> It looks like the decision to explicitly set localstatedir to "/var" in
> the guix package was made in commit 2d195e67 by Ludo. Perhaps he can
> explain what his intent was.

That'd be nice. I'm sure there's a reason which could be helpful in figuring out
how to fix this issue.

> I understand why you would want to do "guix environment guix" (e.g., to
> get the dependencies for guix so you can build it), but I'm curious: why
> would you want to do "guix package -i guix"? This is a bit of a
> digression, but I'm curious to know why one might want do that.

Well, in my case (and a lot of cases as evident by the people running in to this
exact issue) is that we compile Guix from source instead of using the official
binaries, then install Guix so it's managed by Guix. The advantage to this is
that we have all the dependencies for Guix inside the store rather than in, say,
Debian's package manager. This is also needed in the case you want to bootstrap
and install to a disk or build virtual machines containing Guix.

> - Chris

Jookia.

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

[Chris Marusich]

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

I see. Please indulge my curiosity. You said that you "compile Guix from
source instead of using the official
binaries, then install Guix so it's managed by Guix." Do you do this on
GuixSD, or on a foreign distribution? Do you mean that you first compile
and install Guix somewhere on your system, and then run "guix package -i
guix" to install the Guix package into the Guix store? Assuming that's what
you do, which guix-daemon winds up running - the one you installed
originally, or the one you installed into the store? I understand why it's
nice to have the Guix package so that you can easily work with its
dependencies, but isn't "guix pull" the recommended way to keep your Guix
installation up to date?


>

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

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

[Jookia]

On Wed, Feb 17, 2016 at 05:50:31PM +0000, Chris Marusich wrote:
> I see. Please indulge my curiosity. You said that you "compile Guix from
> source instead of using the official
> binaries, then install Guix so it's managed by Guix." Do you do this on
> GuixSD, or on a foreign distribution? Do you mean that you first compile
> and install Guix somewhere on your system, and then run "guix package -i
> guix" to install the Guix package into the Guix store? Assuming that's what
> you do, which guix-daemon winds up running - the one you installed
> originally, or the one you installed into the store? I understand why it's
> nice to have the Guix package so that you can easily work with its
> dependencies, but isn't "guix pull" the recommended way to keep your Guix
> installation up to date?

This is installing on a foreign distribution, though the issue also happens to
those on GuixSD. I can use either the daemon I built or the daemon I have in the
store, I have to start them manually on my distribution. 'guix pull' is the
recommended way to keep your Guix installation up to date, but it's kind of
weird having Guix not be self-contained in the sense of its dependencies.

Jookia.

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

[Andreas Enge]

On Wed, Feb 17, 2016 at 05:50:31PM +0000, Chris Marusich wrote:
> I understand why it's
> nice to have the Guix package so that you can easily work with its
> dependencies, but isn't "guix pull" the recommended way to keep your Guix
> installation up to date?

As far as I know, the only ways of getting the latest and greatest of Guix
is to use "guix pull" or a git checkout. The guix package inside guix
corresponds to a more or less random git commit after the last release,
and is only updated occasionally. In particular, the current version does
not contain all the recent security fixes. So I can only recommend against
using "guix package -i guix".

Andreas

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

[Ludovic Courtès]

Jookia <166291@gmail.com> skribis:

> Over the past month a few people (myself included) have been hit by the 'gotcha'
> of not running ./configure with "--localstatedir=/var".

As discussed on IRC, the expected default values are specified in
<http://www.gnu.org/prep/standards/html_node/Directory-Variables.html>.
I think it’s reasonable to keep following these rules.

However, for the purpose of avoiding bad surprises (configuring Guix
with the wrong localstatedir), I thought we could have a ‘configure’
check that would compare the chosen localstatedir with the current
installation’s localstatedir, and bail out if they don’t match.

WDYT?

Thanks, and apologies for the delay!

Ludo’.

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

[Mathieu Lirzin]

ludo@gnu.org (Ludovic Courtès) writes:

> Jookia <166291@gmail.com> skribis:
>
>> Over the past month a few people (myself included) have been hit by the 'gotcha'
>> of not running ./configure with "--localstatedir=/var".
>
> As discussed on IRC, the expected default values are specified in
> <http://www.gnu.org/prep/standards/html_node/Directory-Variables.html>.
> I think it’s reasonable to keep following these rules.
>
> However, for the purpose of avoiding bad surprises (configuring Guix
> with the wrong localstatedir), I thought we could have a ‘configure’
> check that would compare the chosen localstatedir with the current
> installation’s localstatedir, and bail out if they don’t match.

IMO this is the right way to handle this issue.


-- 
Mathieu Lirzin

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

[Jookia]

On Thu, Mar 17, 2016 at 11:11:40PM +0100, Ludovic Courtès wrote:
> However, for the purpose of avoiding bad surprises (configuring Guix
> with the wrong localstatedir), I thought we could have a ‘configure’
> check that would compare the chosen localstatedir with the current
> installation’s localstatedir, and bail out if they don’t match.

> WDYT?

I think that'd be fantastic, though I'm not sure this would work too well if
you're planning to boostrap. I also submitted some documentation as a patch
which might help. Perhaps it might make sense to make it a variable that needs
to be explicitly set?

> Thanks, and apologies for the delay!
> 
> Ludo’.

Jookia.

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

[Ludovic Courtès]

Jookia <166291@gmail.com> skribis:

> On Thu, Mar 17, 2016 at 11:11:40PM +0100, Ludovic Courtès wrote:
>> However, for the purpose of avoiding bad surprises (configuring Guix
>> with the wrong localstatedir), I thought we could have a ‘configure’
>> check that would compare the chosen localstatedir with the current
>> installation’s localstatedir, and bail out if they don’t match.
>
>> WDYT?
>
> I think that'd be fantastic, though I'm not sure this would work too well if
> you're planning to boostrap. I also submitted some documentation as a patch
> which might help.

Sorry for being slightly disorganized, but could you give me the link to
that patch?  :-)

> Perhaps it might make sense to make it a variable that needs to be
> explicitly set?

Could you explain how that would work?  Not sure what variable we’re
talking about.

Thanks,
Ludo’.

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

[Jookia]

On Fri, Mar 18, 2016 at 07:45:55PM +0100, Ludovic Courtès wrote:
> Sorry for being slightly disorganized, but could you give me the link to
> that patch?  :-)

Here it is:

https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00386.html

> Could you explain how that would work?  Not sure what variable we’re
> talking about.

As in, if you don't explicitly pass --localstatedir configure will error out.
Bit of an extreme example, though.

> Thanks,
> Ludo’.

Cheers,
Jookia.

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

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> As discussed on IRC, the expected default values are specified in
> <http://www.gnu.org/prep/standards/html_node/Directory-Variables.html>.
> I think it’s reasonable to keep following these rules.
>
> However, for the purpose of avoiding bad surprises (configuring Guix
> with the wrong localstatedir), I thought we could have a ‘configure’
> check that would compare the chosen localstatedir with the current
> installation’s localstatedir, and bail out if they don’t match.

Commit ef5f5c8659b1ca3999e362dfa33478e0a0150ced implements a ‘configure’
check such that one gets an error for obvious misconfiguration, and a
warning when the user passed an explicit --localstatedir flag that does
not match (“I know what I’m doing”.)

I believe that should avoid the most common issue.

Comments welcome!

Ludo’.