unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: YOANN P <yoann_mac_donald@hotmail.com>
To: "30768@debbugs.gnu.org" <30768@debbugs.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	[thread overview]
Message-ID: <DB6P18901MB00224E575775984DC00D833CDBD30@DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <87y3ixpfrm.fsf@gnu.org>

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

  reply	other threads:[~2018-03-12 19:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-11 16:08 bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store YOANN P
2018-03-11 20:01 ` YOANN P
2018-03-12 13:47   ` Ludovic Courtès
2018-03-12 19:18     ` YOANN P [this message]
2018-03-12 21:08       ` Ludovic Courtès
2018-03-13 23:48         ` YOANN P
2018-03-14  9:33           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6P18901MB00224E575775984DC00D833CDBD30@DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM \
    --to=yoann_mac_donald@hotmail.com \
    --cc=30768@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).