Re: Another way to deal with the Font Map Problem
Frank Küster <frank@debian.org> wrote:
> I was also thinking about that - I had the same problem with the old
> setup. One possibility to solve the question "who is going to remove
> that file" is: Every package that is involved in this (i.e. tetex-*
> and all the font packages) will remove it upon purge *if* the file is
> empty.
>
> I think, however, that this solution is the most error-prone of all
> suggested, because a single buggy postrm script can break many packages,
> or similarly a loss of /var/lib which not everybody has a backup of will
> break tetex.
Yes...
> There is one other possibility, however. We could patch the updmap
> script (or ask Thomas for this) to run with less restrictive settings
> upon request. This first run would then be used to check which map files
> are not found, and then we could do a second run (either of updmap with
> the needed --disable-map commands, or of update-updmap, omitting the
> files which specify non-existant map files).
I don't like this idea much, because if you opt for the one-run
solution, then updmap will ignore inexistent map files, which can be
confusing for users (a broken config silently failing is usually
confusing). And if you opt for the two-runs solution, it means to are
going to deactivate lines in .cfg files (theoretically, .cfg files
should be deactivated as a whole, when the package that shipped them is
removed, but some map files could live under /usr/local/share/texmf/,
and updmap would find them...), but are you going to fiddle with those
provided by users? No. Then, you would need to be able to distinguish
them from those provided by packages...
> The big disadvantage I see that in this case the relationship between
> conffiles (or other files in updmap.d) and the actual map files for
> dvips, pdftex, dvipdfm is really obscured. With the setup you proposed,
> there will be a magic comment that could also tell users where to
> look. When updmap's output is parsed, the only way to tell which lines
> will end up in updmap.cfg and the actual program map files is to repeat
> the process, or look through all TEXMF trees by hand.
I don't understand this paragraph, sorry. You seem to be suggesting to
tell something else in the magic comment, what is it exactly? The
auto-include (for user .cfg files) or include-only-if-listed-under-/var
(for package-provided .cfg files) policy for .cfg files implied by the
magic comment I was talking about will be documented in
update-updmap(8).
> Therefore I'm inclined to vote for your scheme. I just wanted to spell
> out mine once, so that I really had to think it over, and as a kind of
> brainstorming to inspire other ideas.
OK.
--
Florent
Reply to: