Re: Policy, updmap --enable and updmap.cfg in /etc or /var
Frank Küster <frank@debian.org> wrote:
> But I am not so sure that moving updmap.cfg back to /etc is a good
> idea. It will often be changed by scripts, and when the tetex-packages
> are upgraded and come with a new version of updmap.cfg, the user sees a
> prompt (config file changed by you or a script...) and has a hard time
> to handle it.
[...]
> Hm. Putting updmap.cfg below /var, on the other hand, could be regarded
> to be a policy violation when we no longer have update-updmap. Would it
> be in order to just point the user to --enable and --disable,
> policy-wise?
Hmmm, as the correct handling of /etc/texmf/updmap.d/10lmodern.cfg was
by far the most difficult part in the lmodern packaging, I am not the
person who will defend update-updmap at all cost. *But* I still fear
that removing it would cause a slight regression: in the current
situation, if for whatever reason I want to disable a font (for
instance, suppose I have cm-super installed and I want to produce a PDF
file with the Computer Modern fonts in Type 3 format), I can simply
comment "Map foo.map" in a file under /etc/texmf/updmap.d and be done
with it.
If update-updmap is not there anymore, I'll have to edit updmap.cfg
(using updmap --disable for instance) but presumably, when I update the
font package, it will reenable the font. Or that package would have to
enable the font map files only when it is newly installed... How do you
plan to handle the situation?
Yes, you can probably drop new empty map files under /usr/local to
shadow the normal map files for the font, but it is probably not the
most intuitive solution...
--
Florent
Reply to: