Re: Another way to deal with the Font Map Problem

[Florent Rougon <f.rougon@free.fr>]

Frank Küster <frank@debian.org> wrote:

> This is not only a good idea, it has the advantage that it actually
> works with tetex-3.0, in contrast to the old solution. This week, I
> finally managed to implement the old solution cleanly in my experimental
> packages, only to find out that it has a design flaw.

Aha...


[...]

> tetex-bin.preinst (nothing of interest)
> tetex-bin is unpacked, conffiles are still named *.dpkg-new
> $package.preinst (file is copied to its place)
> $package is unpacked, conffiles are still named *.dpkg-new
> tetex-bin is configured, its conffiles get their real names
> tetex-bin postinst: Wooosh.
>
> The postinst finds $package's file in updmap.d, but the files that are
> referenced therein are still called *.dpkg-new, and updmap fails (it is
> stricter in tetex-3.0).

If I understand correctly, you mean (with the lmodern example) that
/etc/texmf/updmap.d/10lmodern.cfg would be there (because it was created
by lmodern.preinst) and referencing /etc/texmf/dvips/lm.map (without the
full path), which would only exist as /etc/texmf/dvips/lm.map.dpkg-new
until lmodern is configured. And updmap in tetex 3 wouldn't accept that.

> I think this should occur with lmodern and tetex-2.0.2, too, with the
> important difference that updmap, and hence tetex-bin's postinst,
> doesn't fail if it does not find some map files. updmap is simply run
> once again by lmodern's postinst.
>
> I will add a workaround to my packages (simply create the file in
> postinst unconditionally and policy-violating), until I hear from you
> about your implementation plans.

Why do you need to add a workaround?
  - tetex 2 -> you say it doesn't fail;
    [ and what would be the workaround? Copying
      /etc/texmf/dvips/*.map.dpkg-new to /etc/texmf/dvips/*.map? ]
  - tetex 3 -> currently, lmodern is not split, and it will be split
    according to the new plan, which shouldn't fail.

-- 
Florent