On Wed, Oct 19, 2005 at 23:05 +0200, Florent Rougon wrote:
> Ralf Stubner <[EMAIL PROTECTED]> wrote:
> 
> > In the case where this started, the user would have been back at 'square
> > one', since updmap-sys would again try to use the still incorrect
> > /var/lib/texmf/web2c/updmap.cfg and again suggest 'updmap-sys
> > --syncwithtrees' or 'updmap-sys --edit'. 
> 
> I'm not sure I understand whay you mean. I see two cases:
>   - users who encountered #334658 and did not run
>     'updmap-sys --syncwithtrees'
>       -> for these users, the fix I proposed in #334658 must work (I
>          tested it)
>   - users who encountered #334658 and did run 'updmap-sys --syncwithtrees'
>       -> if they blindly follow the same procedure without the rest,
>          they will install lmodern 0.92-9, which will run:
> 
>            update-updmap -> generates a correct
>                             /var/lib/texmf/web2c/updmap.cfg
> 
>            updmap-sys    -> uses the bad updmap.cfg under TEXMFMAIN
> 
>          Doesn't work. They have to remove the bad updmap.cfg from
>          TEXMFMAIN first. Is that what you meant?
> 
> But as far as tetex-bin is concerned, if the bad updmap.cfg is removed
> before the updmap-sys call in tetex-bin.postinst, things should be all
> right, no?

I didn't take lmodern 0.92-9 into account but only thought about
yesterdays situation. A user who encountered #334658 and did run
'updmap-sys --syncwithtrees' will have two updmap.cfg files. One in the
right place but with wrong content (still mentions lm.map), one in the
wrong place (for Debian) but with lm.map commented out. Now a
reconfigure of both tetex-bin and lmodern works, but the LM fonts won't
be available. If however, tetex-bin would delete the updmap.cfg in
/usr/share/texmf/web2c before running updmap-sys, the updmap.cfg in
/var/lib/texmf/web2c would be used. This file still references lm.map,
so updmap-sys would fail again, suggesting to use --syncwithtrees or
--edit. That's what I meant with 'back at square one'. 

Now, with the new lmodern in unstable, this can't happen anymore, but
your second case is still problematic. Maybe the best place to check for
additional updmap.cfg files would be update-updmap. And since one could
go around in circles with simply removing additional updmap.cfg files,
one might have to inform the user about this, present a diff or
something like this ...

cheerio
ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to