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. [EMAIL PROTECTED] http://www.debian.org/