From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: The tricky case of "--localstatedir=/var" Date: Wed, 17 Feb 2016 01:15:17 -0800 Message-ID: <871t8br93u.fsf@gmail.com> References: <20160216135729.GB13560@novena-choice-citizen.lan> <874md7yd4u.fsf@gmail.com> <20160217083849.GA27789@novena-choice-citizen.lan> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVyCg-0002o2-UL for guix-devel@gnu.org; Wed, 17 Feb 2016 04:15:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVyCd-0000TP-Om for guix-devel@gnu.org; Wed, 17 Feb 2016 04:15:22 -0500 Received: from mail-pf0-x22e.google.com ([2607:f8b0:400e:c00::22e]:36294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVyCd-0000TK-HU for guix-devel@gnu.org; Wed, 17 Feb 2016 04:15:19 -0500 Received: by mail-pf0-x22e.google.com with SMTP id e127so8262615pfe.3 for ; Wed, 17 Feb 2016 01:15:19 -0800 (PST) In-Reply-To: <20160217083849.GA27789@novena-choice-citizen.lan> (Jookia's message of "Wed, 17 Feb 2016 19:38:49 +1100") 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: > 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