unpack phase randomly changes the cwd

  • Open
  • quality assurance status badge
Details
4 participants
  • Attila Lendvai
  • Liliana Marie Prikler
  • Maxim Cournoyer
  • Maxime Devos
Owner
unassigned
Submitted by
Attila Lendvai
Severity
normal
A
A
Attila Lendvai wrote on 5 May 2022 13:16
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
IN6Ty5_9Tk68JceEubR3zTKjm8XTJOPv4-llOHUM18euCVLhGnRAeB_ncVn3AC2PbfDu_63Zq0YXlxXYHX8186pUHrciuQdCJCfH8TS69k4=@lendvai.name
at the end of the unpack phase, the working directory is changed to a random directory.


this is fine *when* the archive contains a single dir... but this DWIM'ness has just burned 15 mintues of my life, and i recommend removing it.

if it is to stay, then at least it should be patched that it only happens when the dir after extraction only contains a single subdir, and no files otherwise.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“When men hire themselves out to shoot other men to order, asking nothing about the justice of their cause, I don’t care if they are shot themselves.”
— Herbert Spencer (1820–1903), during Britain's second Afghan war
M
M
Maxime Devos wrote on 5 May 2022 14:18
378a823f4ae3a60c2d3ad419b22958524c933b19.camel@telenet.be
Attila Lendvai schreef op do 05-05-2022 om 11:16 [+0000]:
Toggle quote (4 lines)
> at the end of the unpack phase, the working directory is changed to a random directory.
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm#n178

It takes the first result 'scandir' -- i.e., the 'smallest' file name
according to string-locale<?, so technically it's not random (so no
reproducibility problems)

Toggle quote (5 lines)
>
> this is fine *when* the archive contains a single dir... but this DWIM'ness has just burned 15 mintues of my life, and i recommend removing it.
>
> if it is to stay, then at least it should be patched that it only happens when the dir after extraction only contains a single subdir, and no files otherwise.

Except maybe when using 'out-of-source?', I think it has to stay in
some form -- somehow, we will have to run build scripts, "make", maybe
do some 'substitute*', and having to type the version number and
directory name inside build phases seems a bit error-prone (what if the
source is changed fom tarball or 'zip' to a vcs checkout?).

I agree with only chdiring if there's only one subdir (and no other
files) though -- ‘just the first’ is a bit arbitrary.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYnPAjRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7hcPAQCFW/Nxza6Q/6DPskwK3/dzFebz
aUV1g5TI31LsC29bPwD/SVm+R3wlX4KhqNDtMtfQ3vKEDM/rLKd+8HkMLCSshgc=
=ci5l
-----END PGP SIGNATURE-----


A
A
Attila Lendvai wrote on 5 May 2022 15:15
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 55270@debbugs.gnu.org)
Bp8HCSiQBKqwlPg7xZPY-2mqTh7jppBKwk0rBCg5cJ2N7MHGm2ci-jsXnKjRqDRc7N2oXR5xJ_eeekBJfUZQew45gnA1WeGFTMwMEcGZ0_I=@lendvai.name
Toggle quote (5 lines)
> It takes the first result 'scandir' -- i.e., the 'smallest' file name
> according to string-locale<?, so technically it's not random (so no
> reproducibility problems)


fair enough. what i meant to communicate is that it's arbitrary, not random.

another potential issue:

if the root of the archive contains a file called 'environment-variables', then this way it would overwrite the one generated by Guix. this may not necessarily be an issue, though, if that file is never used after the unpack phase.

maybe the cleanest would be to:

1) mkdir a directory ('extracted/'?) and chdir into it prior to
unpacking, and

2) only do the DWIM chdir if the toplevel of the archive was a single
dir.

but i lack the necessary perspective to see all the implications.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There is always a philosophy for lack of courage.”
— Albert Camus (1913–1960)
L
L
Liliana Marie Prikler wrote on 5 May 2022 22:12
Re: unpack phase randomly changes the cwd
fbb7b66bf0ff1ec2bf9dc58679f7d1b231dc3777.camel@gmail.com
Am Donnerstag, dem 05.05.2022 um 11:16 +0000 schrieb Attila Lendvai:
Toggle quote (8 lines)
> at the end of the unpack phase, the working directory is changed to a
> random directory.
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm#n178
>
> this is fine *when* the archive contains a single dir... but this
> DWIM'ness has just burned 15 mintues of my life, and i recommend
> removing it.
url-fetch/tarbomb: Now this looks like a job for me.
M
M
Maxim Cournoyer wrote on 12 Jul 2022 16:11
Re: bug#55270: unpack phase randomly changes the cwd
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87a69e8lp9.fsf@gmail.com
Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (12 lines)
> Am Donnerstag, dem 05.05.2022 um 11:16 +0000 schrieb Attila Lendvai:
>> at the end of the unpack phase, the working directory is changed to a
>> random directory.
>>
>> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm#n178
>>
>> this is fine *when* the archive contains a single dir... but this
>> DWIM'ness has just burned 15 mintues of my life, and i recommend
>> removing it.

> url-fetch/tarbomb: Now this looks like a job for me.

Just to make sure, are you suggesting the archive type used here would
have been better handled by url-fetch/tarboom?

Thanks,

Maxim
L
L
Liliana Marie Prikler wrote on 12 Jul 2022 18:47
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87d3668336bb407c14cbb5fe908a408b759ebe95.camel@gmail.com
Am Dienstag, dem 12.07.2022 um 10:11 -0400 schrieb Maxim Cournoyer:
Toggle quote (20 lines)
> Hi,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > Am Donnerstag, dem 05.05.2022 um 11:16 +0000 schrieb Attila
> > Lendvai:
> > > at the end of the unpack phase, the working directory is changed
> > > to a
> > > random directory.
> > >
> > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm#n178
> > >
> > > this is fine *when* the archive contains a single dir... but this
> > > DWIM'ness has just burned 15 mintues of my life, and i recommend
> > > removing it.
>
> > url-fetch/tarbomb: Now this looks like a job for me.
>
> Just to make sure, are you suggesting the archive type used here
> would have been better handled by url-fetch/tarboom?
That's what the docstring of url-fetch/tarbomb leads me to believe,
yes. Is it not helpful?
?