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

Re: Another way to deal with the Font Map Problem



Florent Rougon <f.rougon@free.fr> wrote:

> Florent Rougon <f.rougon@free.fr> wrote:
>
> The problem is: who is going to remove the file we called
> /var/lib/tetex/disabled-fontmap-cfg (the one storing the list of .cfg
> files that update-updmap should ignore)? We were all thinking---or not
> thinking at all---tetex-bin or tetex-base, I guess, but I think it is
> possible to purge tetex-* while keeping $fontpackage installed. It will
> just be deconfigured (if it depended on one of the tetex packages).

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.

>   (d) add a magic comment[1] at the top of the .cfg files that are
>       provided by packages, which would tell update-updmap to apply the
>       ignore-unless-listed-under-/var/lib/tetex/fontmap-cfg/ policy.

I'd vote for (d), too. 

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).

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. 

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.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Reply to: