Hi Wiktor,
> On Tue, Sep 10, 2019 at 04:37:03PM +0200, Ricardo Wurmus wrote: > >> This sounds like perhaps you ran “./configure” without >> “--localstatedir=/var”, 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’s precisely what happened. I missed (or just lazily, > hastily ignored) the “Make sure to pass --localstatedir=directory” > sentence. I’m glad there exists at least an explanation for that > disaster. > > Don’t you think it would be reasonable to follow that sentence with > something like: *Otherwise, you risk that the default store in `/gnu` > becomes damaged*? I think this failure mode is pretty terrible and I’m really sorry that you encountered it. I think it’s 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 — luckily Guix failed to delete things early due to a permission problem, so I didn’t 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—for which steps. Using a git checkout and an environment is the recommended way to contribute to Guix, because you’ll have access to the most current version of Guix. Building with “./pre-inst-env guix build” 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’d have a hard time contributing to Guix. -- Ricardo
