Hi Yoann, YOANN P <[email protected]> skribis:
>> 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. In general we’re very cautious about changing what goes into the build environment. The daemon provides isolated build environments, and things will behave differently if we start adding/removing directories or files; even simple changes like this can easily hinder reproducibility. >> 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. OK, I see. That’s a worthy goal and a neat hack (I don’t think it’s been tried before.) >> 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 ? >From m4/guix.m4: --8<---------------cut here---------------start------------->8--- dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing zero.) dnl The Hurd has a limit of about a page (see exec/hashexec.c.) m4_define([LINUX_HASH_BANG_LIMIT], 127) dnl Hardcoded 'sun_path' length in <sys/un.h>. m4_define([SOCKET_FILE_NAME_LIMIT], 108) --8<---------------cut here---------------end--------------->8--- >> 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. Understood. Are you in a situation where user namespaces are unavailable? HPC? Thanks, Ludo’.
