On Sun, Sep 09, 2007 at 11:08:19AM +0400, Sergei Golovan wrote: > On 8/28/07, Russ Allbery <[EMAIL PROTECTED]> wrote:
> > I don't have any time to work on this, but it occurred to me reading this > > that it might be useful for QA purposes to have a version of debuild that > > *unsanitizes* the environment to test robustness. An evil-debuild that > > sets every problematic environment variable that it can think of (TAPE, > > QUILT_PATCHES, LANG, LC_ALL, PWD, etc.), builds the source in a directory > > name containing a space, and otherwise tries all the environmental things > > that have broken packages in the past. > One of the packages co-maintained by me FTBFS if HOME environment > variable points to an existing inaccessible directory. (See > http://buildd.debian.org/fetch.cgi?&pkg=wings3d&ver=0.98.36-4&arch=mipsel&stamp=1189251602&file=log) > Should this be treated as a bug in buildd configuration or package > maintainers should take into account the possibility of so unusual > HOME behavior? It's a bug in your package. Packages should not rely on anything in $HOME for building, and should definitely not write anything to $HOME, as packages are not supposed to modify anything outside of the build directory during build. The reason the mipsel buildd has a non-writable home is precisely because it previously /did/ have a writable home, and various packages would in the process of building pollute it with contents that would break subsequent package builds. This way, all packages that depend on reading from /or/ writing to $HOME break equally. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
