guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jookia
Subject: Re: The tricky case of "--localstatedir=/var"
Date: Wed, 17 Feb 2016 19:38:49 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]