Re: Braindump: Can we get rid of the font-cache-group question?
On Mon, May 22, 2006 at 22:34 +0200, Frank Küster wrote:
> > ${MT_FEATURES=3Dappendonlydir:varfonts}
> >
> > (probably similar for TeX Live). From what I read in TETEXDOC section
> > 2.6, I think that we would be better off with
> >
> > ${MT_FEATURES=3Dtexmfvar}
>
> Yes; strange that MT_FEATURES is set twice, first in mktex.opt, then
> overridden in mktex.cnf.
Actually mktex.opt sources mktex.cnf first. The parameter expansion in
mktex.opt does not have an effect then, since MT_FEATURES is already
set. From the kpathsea docu is seems as if normally mktex.cnf isn't
installed, but this is different with teTeX.
> I put a copy of mktex.cnf into
> /etc/texmf/web2c/, changed the setting, and it works.
Good to know. I have only worked from the docs (and a bit of the code)
up to now. No tests. ;-)
> > For single-user machines or buildds I see no
> > disadvantage. Comments?
>
> My only concern is: On a build system, can we really assume that there
> is a valid home directory where we can create directory trees and
> (possibly lots of) files?
Unfortunately that is a very valid concern. I don't know about buildds,
but I can login into my pbuilder such that I don't get a valid $HOME
(sudo without -H). Two possible solutions come to my mind right now:
. Stick with a debconf question, but with a simpler choice: World
writable font cache (default) or per user font cache via MT_FEATURES.
We could still document how to setup a shared but not world writable
font cache.
. Don't set VARTEXFONTS. If I interpret the code in mktexnam and
mktex.opt correctly, VARTEXFONTS is used if the texmfvar feature is
set but TEXMFVAR cannot be used for some reason. If VARTEXFONTS is not
set, it will default to the current directory, which should always be
writable.
In the first case, we would still have a debconf question and a less
than ideal default setting. In the second case, old cached font data
would get useless, since /var/cache/fonts is no longer searched. I am
also not sure if it is a problem for build systems if suddenly lots of
files a re produced in a location not expected by the developer. For
example, 'debian/rules clean' would probably not remove them. There
are possibly other issues, especially when upgrading a system.
cheerio
ralf
Reply to: