Re: many packages FTBFS, if $TAPE is set
On Sun, Sep 09, 2007 at 11:08:19AM +0400, Sergei Golovan wrote:
> On 8/28/07, Russ Allbery <email@example.com> 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
> 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
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.