GNU bug report logs - #35387
unpack phase in gnu-build-system is non-deterministic

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35387 in the body.
You can then email your comments to 35387 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guix <at> gnu.org
Subject: unpack phase in the gnu-build-system is sometimes non-deterministic
Date: Tue, 23 Apr 2019 08:16:25 +0100

[Message part 1 (text/plain, inline)]

I believe that the direnv package has encountered an issue with the
gnu-build-system [1].

1: https://issues.guix.info/issue/35386

Due to the combination of the 'setup-go-environment phase from the
go-build-system, and the 'unpack phase of the gnu-build-system, there
are two directories to be considered by first-subdirectory when called
from the unpack phase.

It seems from direnv that this either consistently, with the package
working on one machine, or failing consistently on another.

To avoid issues like this in the future, I think it would be good to
have first-subdirectory raise an error if it's behaviour could be
non-deterministic.

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 35387 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 35387 <at> debbugs.gnu.org
Subject: Re: bug#35387: unpack phase in the gnu-build-system is sometimes
 non-deterministic
Date: Tue, 23 Apr 2019 16:36:40 +0200

Hi Chris,

Christopher Baines <mail <at> cbaines.net> skribis:

> I believe that the direnv package has encountered an issue with the
> gnu-build-system [1].
>
> 1: https://issues.guix.info/issue/35386
>
> Due to the combination of the 'setup-go-environment phase from the
> go-build-system, and the 'unpack phase of the gnu-build-system, there
> are two directories to be considered by first-subdirectory when called
> from the unpack phase.
>
> It seems from direnv that this either consistently, with the package
> working on one machine, or failing consistently on another.
>
> To avoid issues like this in the future, I think it would be good to
> have first-subdirectory raise an error if it's behaviour could be
> non-deterministic.

‘file-system-fold’ is just a wrapper around ‘readdir’ so the order in
which it sees directory entries is non-deterministic.

What about writing it like this:

  (define (first-subdirectory directory)
    "Return the file name of the first sub-directory of DIRECTORY."
    (match (scandir directory
                    (lambda (file)
                      (and (not (member file '("." "..")))
                           (file-is-directory? (string-append directory "/"
                                                              file)))))
      ((first . _) first)))

The result will be deterministic since ‘scandir’ sorts entries.

Thanks,
Ludo’.

Message #11 received at 35387 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 35387 <at> debbugs.gnu.org
Subject: Re: bug#35387: unpack phase in the gnu-build-system is sometimes
 non-deterministic
Date: Tue, 30 Apr 2019 08:02:04 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Chris,
>
> Christopher Baines <mail <at> cbaines.net> skribis:
>
>> I believe that the direnv package has encountered an issue with the
>> gnu-build-system [1].
>>
>> 1: https://issues.guix.info/issue/35386
>>
>> Due to the combination of the 'setup-go-environment phase from the
>> go-build-system, and the 'unpack phase of the gnu-build-system, there
>> are two directories to be considered by first-subdirectory when called
>> from the unpack phase.
>>
>> It seems from direnv that this either consistently, with the package
>> working on one machine, or failing consistently on another.
>>
>> To avoid issues like this in the future, I think it would be good to
>> have first-subdirectory raise an error if it's behaviour could be
>> non-deterministic.
>
> ‘file-system-fold’ is just a wrapper around ‘readdir’ so the order in
> which it sees directory entries is non-deterministic.
>
> What about writing it like this:
>
>   (define (first-subdirectory directory)
>     "Return the file name of the first sub-directory of DIRECTORY."
>     (match (scandir directory
>                     (lambda (file)
>                       (and (not (member file '("." "..")))
>                            (file-is-directory? (string-append directory "/"
>                                                               file)))))
>       ((first . _) first)))
>
> The result will be deterministic since ‘scandir’ sorts entries.

That sounds great :)

[signature.asc (application/pgp-signature, inline)]

Message #18 received at 35387-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 35387-done <at> debbugs.gnu.org
Subject: Re: bug#35387: unpack phase in the gnu-build-system is sometimes
 non-deterministic
Date: Fri, 14 Jun 2019 23:43:43 +0200

Ludovic Courtès <ludo <at> gnu.org> skribis:

> What about writing it like this:
>
>   (define (first-subdirectory directory)
>     "Return the file name of the first sub-directory of DIRECTORY."
>     (match (scandir directory
>                     (lambda (file)
>                       (and (not (member file '("." "..")))
>                            (file-is-directory? (string-append directory "/"
>                                                               file)))))
>       ((first . _) first)))
>
> The result will be deterministic since ‘scandir’ sorts entries.

Pushed as cfd4e4d06e3cda0f3eed8d6b9277ce53e55404b8 on ‘core-updates’.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.