Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

[Steve Langasek <vorlon@debian.org>]

On Sat, Sep 30, 2006 at 11:31:14AM +0200, Frank Küster wrote:
> > But if the package build requires access to $HOME/.texmf-var, that's still a
> > bug that should be fixed; 

> No it doesn't require that.  Only if there is a $HOME directory, and it
> is writable, then it is used.  Otherwise /tmp/texfonts is used
> instead. 

I've chatted with Ryan Murray about this, who maintains the buildds for the
three archs in question.  He's agreed to look into removing /home/buildd on
these buildds when he has a chance.

However, he also agrees with me that every package affected by this bug is
violating policy in its package builds: a package's clean target has to undo
everything done by the build and binary targets, which is not possible if
it's leaving cache files around on the system.  (The fact that buildds don't
actually call the clean target after calling the binary target is secondary,
really; the point is that package builds shouldn't be writing to the user's
home directory in the first place and *requiring* any cleanup, though I
can't find any reference to this in the current version of policy.)

Ryan suggests that not caching fonts at all would be a good solution to
this.  Since AIUI it is a design constraint of tex to cache these fonts as
intermediary output from one tool used as input for another, the next best
option is for the tex maintainers to provide documentation to package
maintainers who build-depend on tex for using a local, in-tree font cache
that they can wipe out as part of their clean target, leaving the rest of
the system unaffected.

Had this been in place for whatever packages are generating documentation in
their binary target (instead of their build target), the autobuilders never
would have ended up with root-owned directories under
/home/buildd/.texmf-var (which Ryan confirms is the case).  Had it been in
place for the packages that are currently failing to build, they wouldn't be
failing to build.  This makes it the preferable, most robust solution, not
depending on other packages to behave themselves wrt any caches that might
exist on the system.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/