From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: ./pre-inst-env guix build dangerous inside an environment? Date: Wed, 11 Sep 2019 21:40:45 +0200 Message-ID: <87tv9ipqo2.fsf@elephly.net> References: <20190910135802.lorsnzuaofjxifwy@wz.localdomain> <87a7bcqkts.fsf@elephly.net> <20190911161800.g6lzpfmfttsxgxmf@wz.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:37437) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i88ii-0000gk-Hh for help-guix@gnu.org; Wed, 11 Sep 2019 15:56:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i88ih-0001db-9m for help-guix@gnu.org; Wed, 11 Sep 2019 15:56:04 -0400 Received: from sender4-of-o52.zoho.com ([136.143.188.52]:21201) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i88ih-0001d0-1r for help-guix@gnu.org; Wed, 11 Sep 2019 15:56:03 -0400 In-reply-to: <20190911161800.g6lzpfmfttsxgxmf@wz.localdomain> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Wiktor =?utf-8?Q?=C5=BBelazny?= Cc: help-guix@gnu.org Hi Wiktor, > On Tue, Sep 10, 2019 at 04:37:03PM +0200, Ricardo Wurmus wrote: > >> This sounds like perhaps you ran =E2=80=9C./configure=E2=80=9D without >> =E2=80=9C--localstatedir=3D/var=E2=80=9D, so that Guix would be using a = different >> location for its database and thus consider existing stuff in /gnu to >> be invalid. > > Thank you for your prompt reply, Ricardo. > > Yeah, that=E2=80=99s precisely what happened. I missed (or just lazily, > hastily ignored) the =E2=80=9CMake sure to pass --localstatedir=3Ddirecto= ry=E2=80=9D > sentence. I=E2=80=99m glad there exists at least an explanation for that > disaster. > > Don=E2=80=99t you think it would be reasonable to follow that sentence wi= th > something like: *Otherwise, you risk that the default store in `/gnu` > becomes damaged*? I think this failure mode is pretty terrible and I=E2=80=99m really sorry t= hat you encountered it. I think it=E2=80=99s not a good idea for Guix to delete stuff from /gnu/store just because the database says that the directories are invalid. I also suffered from this problem in the big production environment at the institute where I work =E2=80=94 luckily Guix failed to delete things e= arly due to a permission problem, so I didn=E2=80=99t lose all of /gnu. I wonder if the daemon should just abort with an error when it encounters an unknown directory. The problem with that is that sometimes directories are left behind when the daemon was forcibly killed, and we want those to be cleaned up automatically. @Ludo, what do you think about this? >> This is not a problem with using an environment. > > Still, it seems to me unclear from the manual (at least as far as > 14.2 is concerned) whether anything is gained by doing test builds in > an environment, and thus whether this is the recommended way, and if > so=E2=80=94for which steps. Using a git checkout and an environment is the recommended way to contribute to Guix, because you=E2=80=99ll have access to the most current version of Guix. Building with =E2=80=9C./pre-inst-env guix build=E2=80=9D= lets Guix use the (potentially modified) source checkout, so you have access to work-in-progress package definitions before they are added to Guix proper. Once the build is successful you can submit a patch and the package would eventually become part of Guix. Without a git checkout (and an environment to provide the required dependencies to work with it) you=E2=80=99d have a hard time contributing to Guix. -- Ricardo