On 11/26/2016 01:59 AM, Ross Vandegrift wrote: > On 11/11/2016 0826:45 AM, Christian Seiler wrote: >> pbuilder sets the home directory of the pbuilder user to /nonexistent >> to make sure that builds don't modify files in the home directory, >> which is forbidden by Debian Policy (for good reason builds are not >> supposed to change things outside the build directory). > > Could you point me to this policy? I'd like to learn more, but haven't > been able to find it.
I just checked and it really isn't in there. OTOH, there have been bug reports with severity serious about this issue since forever; a quick search randomly gave me the following reports within 1 minute, and then I stopped looking: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415367 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469903 My guess is that it probably never got added to policy because autobuilders fail with similar errors as pbuilder does, so packages that violate this FTBFS, which is an automatic RC bug, regardless of policy. And probably also because most people find this principle so obvious. Btw. notable exception is /tmp (or $TMPDIR, if that's set), as long as there is cleanup afterwards. Many compilers tend to use /tmp for temporary files. (gcc does by default unless you specify -pipe.) > Two probably naive questions: > > 1) Why? (I can imagine reasons, but don't want to assume that I know) Well, because of side effects. Suppose you want to fix a bug in a package you're using, and there is some patch already available online, and you just want to rebuild the package with that patch included, but you don't really understand all details of the entire build system etc. of the package (even though you might understand the patch itself) - what if the package then just modifies configuration in your home directory? Or installs stuff there? What if your home directory has limited space available and you're building on a different partition - but then suddenly the partition with your home directory is full just because of a package build that has side effects. There are tons of reasons why builds should be self-contained, and I think this is something that should IMHO be very obvious. Also, this is a good practice irrespective of Debian, upstream packages should do the same in principle. (And most do.) Now in the case of build systems that have a feature to automatically download dependencies this is a bit more complicated (because the user might want that feature), so I understand why upstream might deviate from that principle in this specific case. [1] But in general at least I see no reason for any build system to not be self-contained within the source directory of the package. (Technically, if the system supports out of tree builds, as many traditional systems such as automake or cmake do, it should even be contained in the build directory only and not modify the source directory at all.) > 2) Is there a common pattern for handling upstream tests that break this > rule? Maybe there's an alternative to disabling them? If upstream tests do that, I would suggest sending a patch upstream that fixes them, because especially for tests I would consider this a bug. That said, if tests just require stuff in the home directory you could set the HOME environment variable to a temporary directory within the build tree before you run the tests, to work around this kind of problem. Nevertheless I would consider those tests buggy and would want to patch them. If you could give a couple of examples of what exactly you're thinking of, maybe my answer could be more specific. Regards, Christian [1] But even there I dislike this. I don't think running a build should install stuff. I could get behind a build system having a separate command line command for downloading the dependencies automatically that the user could explicitly call if required, and maybe a combined command for doing both at the same time, but I do think that a command to "just build, and fail if deps not available" should be easily available in any sane build system, for various reasons. (The famous "dissident test", but even more trivial things such as being behind a metered connection.)
