[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to use update-updmap safely [was: Bug#231235: arabtex font installation is broken]



Hi,

Hilmar Preusse <hille42@web.de> wrote:

> Sorry.
> BTW: Are you subscribed to debian-tetex-maint or do I have to keep
> you in Cc? I'm taking the bug out, as it has nothing to do with it.

I am subscribed to the list.

> updmap uses kpsewhich, so we have to run texhash before calling
> updmap. We could hard code the mktexlsr call into update-updmap.

This would make update-updmap much slower and it would no longer exactly
do what the name "update-updmap" implies, but it would be safer.

> Assuming, that updmap *creates* new files, instead of just updating
> files, which already exist. Well it does create files during
> installing teTeX, but not during installation of additional packages.
> As there may occur new files, when a new version of teTeX is
> released it is probably a good idea, to run mktexlsr.

But unless told otherwise, updmap runs texhash after it has
created/updated the maps, so we don't need to run mktexlsr after updmap.

> As mktexupd is not sitting in /usr/../{s,}bin it is probably not made
> for the end user. mktexlsr is much safer.

Agreed. mktexupd has no man page either (well, updmap didn't have one
until Claire M. Connelly wrote it... Thanks, Claire!). I think Thomas
Esser considers it as a teTeX internal.

> Finally: Your proposal above sounds reasonable. We should document
> that in Readme.Debian or hard code mktexlsr into update-updmap.
> Comments?

I have no strong preference over one approach or the other... Well, if
there are few packages that use update-updmap and their maintainers are
careful, I would vaguely prefer to simply document the fact that one has
to run update-updmap, mktexlsr, and updmap in this order. This way, if
the admin adds or modifies a file in /etc/texmf/updmap.d, updating
updmap.cfg to reflect this change is very quick.

I don't care much, really.

-- 
Florent



Reply to: