GNU bug report logs - #30768
Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store

Previous Next

Full log

View this message in rfc822 format

From: YOANN P <yoann_mac_donald <at> hotmail.com>
To: "30768 <at> debbugs.gnu.org" <30768 <at> debbugs.gnu.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store
Date: Mon, 12 Mar 2018 19:18:24 +0000

Hi Ludovic,

> We won’t apply this patch because in general there’s no reason for build
> processes to require /var/tmp (we’ve never encountered that.)

There's always a first time. Since i didn't encounter this behavior with other 
custom directories than i've tested, looking at the code of the test who failed,
i suppose than the store dir is mounted inside the build chroot as itself and is 
the reason why "/var/tmp" exist during the build with a store dir starting by 
"/var/tmp".

Despite the fact that generally there’s no reason for build processes to require 
/var/tmp, is there any risk to add it to the chroot dirs ? If yes (or didn't want to 
add it), maybe a warning about the fact than we should never use a directory 
inside "/var/tmp" as store should maybe be add (it will had saving me many 
hours banging my head) because i've never read somewhere that there was 
some forbidden directories to use as store and it seems there is some 
regarding the bug i encounter.

> That said, are you sure you want to use
> --with-store-dir=/var/tmp/xxxxx/gnu/store?

Yeah, i'm pretty sure i did want to use this kind of path even if it sounds 
weird or the reasons are not good. The purpose of my tests was to 
configure the store with a symlink /var/tmp/guix-[short-hash] who is 
pointing to a directory where i have the rights. This way, i could use 
my environment with user X on server A or user Y on server B only by 
adapting my symlink.

This way, i could achieve a unprivileged portable environment because 
/var/tmp seems present and writable on all major distribution, plus it 
seems to work even if /var/tmp is mount with noexec.

> You probably got a ‘configure’ warning already that certain things may
> not work, for instance that the shebang max length may be exceeded.

Regarding the warning , i just checked my ./configure log, and there is 
no warning about the limit length for the store path due to the limit of 
shebang length, only a warning regarding the substitutes.

Even if i was aware of it after reading Pjotrp notes, i've never found a 
clear limit after my readings on the web. If Guix Team has an idea of 
the store path limit lenght, it could be a great idea to add it to the docs 
or did i missed it ?

> Also using a store other than /gnu/store means you won’t be able to use
> substitutes, nor to compare build results with other machines.

I'm pretty aware of that, but having a portable environment who could be 
used even under unprivileged user without the needing of "proot" / 
"usernamespace" come with some trade offs and is just a proof of concept 
even if it is require to build all packages from scratch.

> Thanks,
> Ludo’.
 
Regards,
Yoann

Previous Next

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