Re: ./pre-inst-env guix build dangerous inside an environment?

[Ricardo Wurmus <rekado@elephly.net>]

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