From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: The tricky case of "--localstatedir=/var" Date: Tue, 16 Feb 2016 15:29:02 +0100 Message-ID: References: <20160216135729.GB13560@novena-choice-citizen.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVgcx-0003BZ-5V for guix-devel@gnu.org; Tue, 16 Feb 2016 09:29:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVgct-0006UQ-41 for guix-devel@gnu.org; Tue, 16 Feb 2016 09:29:19 -0500 Received: from venus.bbbm.mdc-berlin.de ([141.80.25.30]:38575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVgcs-0006TP-RJ for guix-devel@gnu.org; Tue, 16 Feb 2016 09:29:15 -0500 In-Reply-To: <20160216135729.GB13560@novena-choice-citizen.lan> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Jookia <166291@gmail.com> Cc: guix-devel@gnu.org 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=3D/var". It doesn't sa= y this in > the documentation but I question whether not having it as /var is a san= e > 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 Gu= ix > without localstatedir in /var would not only be a weird idea, it will a= ctually > *break* things. See avahi, xorg-server, findutils. I like this because I assume most people really don=E2=80=99t want to hav= e 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 Gui= x 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=E2=80=99m actually doing this on my cluster installation. It=E2=80=99s= 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 =E2=80=9C/gnu=E2=80=9D and =E2=80=9C/gnu/var=E2=80=9D ha= ve to be mounted separately and sequentially with different flags: =E2=80=9C/gnu=E2=80=9D should be read-= only in general (in particular =E2=80=9C/gnu/store=E2=80=9D) and =E2=80=9C/gnu/var/guix/p= rofiles=E2=80=9D must be read-writeable for users to be able to install things into their profiles. One thing that doesn=E2=80=99t work out of the box is users installing gu= ix with guix, because that=E2=80=99s preconfigured for a localstatedir in =E2=80=9C= /var=E2=80=9D. (The easy fix is to overwrite the guix package definition.) > * Instruct people to always pass "--localstatedir=3D/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 ar= ound for > profiles and isn't easily explained to people. > > More importantly, people are going to come away from their Guix experie= nce 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 =E2=80=9Clocalstatedir=E2=80=9D flag (and its default value) = in the manual, but I=E2=80=99d like to cast my vote for one of the two previous suggesti= ons. > The advantage this approach has is that localstatedir is configurable. > Unfortunately, packages will still be broken. Perhaps it's time to subs= titute > 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