[tex-live] luaotfload-tool writes database to TEXMFSYSVAR if writable
jfbu at free.fr
Mon May 16 11:18:11 CEST 2016
Le 16 mai 2016 à 11:06, Norbert Preining <norbert at preining.info> a écrit :
> On Mon, 16 May 2016, jfbu wrote:
>> My question to TeXLive generally is: is this behaviour of luaotfload
>> the expected one, are executables expected to write to the first
>> repertory where they have write access ?
> My answer from TeX Live: Complain to the author's of luaotfload.
> I also consider it strange, but *we* will not hack around in the script.
>> I will open a ticket only if needed on luaotfload github repo
>> depending on answers received here.
> I think it makes sense.
Thanks for the reply, here is some more info. First of all,
the database build does not need to be invoked by luaotfload-tool -u,
it can be triggered from a document accessing a not yet known font.
Second: turns out that if 2016b/texmf-var/luatex-cache does not exist,
it will be create naturally using the umask of the account.
Thus user YYY with umask 755 and write access to 2016b/texmf-var
will thus produce a 2016b/texmf-var/luatex-cache
which is non writable to user XXX having nevertheless write access
This creates a problem when XXX tries to compile
with CourierStd.otf a font which was not known to YYY account:
luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: "File not found: CourierStd.otf.".
luaotfload | db : Index file not writable
luaotfload | db : Failed to write /usr/local/texlive/2016b/texmf-var/luatex-cache/generic/names/luaotfload-names.lua.
luaotfload | db : Failed to write /usr/local/texlive/2016b/texmf-var/luatex-cache/generic/names/luaotfload-names.luc.
luaotfload | db : Failed to save database to disk: nil
luaotfload | cache : Lookup cache file not writable.
luaotfload | cache : Failed to write /usr/local/texlive/2016b/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.lua.
luaotfload | cache : Failed to write /usr/local/texlive/2016b/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.luc.(compili
ng luc: /usr/local/texlive/2016b/texmf-var/luatex-cache/generic/fonts/otl/couri
Nevertheless the last lines indicate that luaotfload found a
way to overcome the problem, and the produced pdf is *fine*,
despite the fact that the general name database of fonts
could not be updated.
I think however that nothing of this would happen if luaotfload
by default obeyed TEXMFVAR rather than using TEXMFSYSVAR if the
latter is writable.
There might be some reason to it, though.
More information about the tex-live