Re: many packages FTBFS, if $TAPE is set
On Sun, Sep 09, 2007 at 11:26:14AM +0400, Sergei Golovan wrote:
> > > 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.
> It would be sufficient (for this particular package) to point HOME to
> a truly unexistent directory. Is there a reason why /unexistent exists
> in buildd chroot?
Because one of the other buggy packages that messes with $HOME, and with
which your package has to share a build environment on the buildds, created
it. (So in a sense, yes, this is a bug in the build environment too, but
your package still has a bug.)
> But OK, I'll try to fix the package (setting HOME inside debian/rules
> should help).
> > 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.
> So, mipsel buildd is a test station for HOME related bugs?
No, the HOME=/nonexistent setting is there to in theory control the kinds of
HOME-related bugs that occur.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.