Re: many packages FTBFS, if $TAPE is set
On 9/9/07, Steve Langasek <vorlon@debian.org> wrote:
> On Sun, Sep 09, 2007 at 11:08:19AM +0400, Sergei Golovan wrote:
>
> > 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.
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?
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?
--
Sergei Golovan
Reply to: