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
