Re: Another way to deal with the Font Map Problem
Florent Rougon <f.rougon@free.fr> schrieb:
> Frank Küster <frank@debian.org> wrote:
>
>> No, not exactly. We could run (the second time) updmap with "--disable
>> $notfoundmap". The files in /etc/texmf/updmap.d/ would not be changed,
>> but /var/lib/texmf/web2c/updmap.cfg would not contain all lines that are
>> in *.cfg files in updmap.d.
>
> Umm, for me, calling updmap --disable in Debian maintainer scripts is
> verboten, because it modifies the user-configuration... We already
> talked about that when discussing whether there was still a good reason
> to use update-updmap.
In theory I agree (although updmap.cfg is not a confile). In practice,
tetex's maintainer scripts bluntly refuse to leave things in
configuration files if they know that this will cause the script to fail
- e.g. we are commenting ukhyphen.tex in language.dat. I would be
willing to look at this from a similar viewpoint. On the other hand, of
course it is a difference whether fiddling with user configuration is
done in cases of emergency, or as part of a newly established policy.
Well, I never really meant to advocate this scheme. I just wanted to
explain how it could work, technically
> OK. I implemented the new scheme based on tetex-base_2.96.5.20040711-4
> and tetex-bin_2.96.7.20040721-1 from your p.d.o. space. You can find the
> result here:
>
> http://people.via.ecp.fr/~flo/tmp/tetex-beta/
I'll have a look at it, thank you very much.
> [ Open for discussion: whether to run try_to_update_fontmaps() on purge,
> i.e. update-updmap, mktexlsr and updmap. This takes a while, and is
> usually useless because purge is usually called after remove, which
> already did that. It is not useless if the user removed the lmodern,
> broke his config (map files, or whatnot) and then purges lmodern.
> Running try_to_update_fontmaps() might fix his broken config at this
> point but I am not sure it is worth annoying all other users just for
> that, we should rarely happen and is a user error anyway.
and dpkg-reconfigure tetex-bin (or any TeX-font-related package) will do
the same, won't it?
> So, I chose to disable try_to_update_fontmaps() on purge for this
> experimental package. This has a minor side effect: if I purge
> lmodern, since try_to_update_fontmaps() is last run when postrm is
> called with $1 = remove, the resulting updmap.cfg contains:
>
> #
> ### /etc/texmf/updmap.d/10lmodern.cfg not included because the
> ### corresponding package seems to be removed.
> #
Hm, well, this is not nice. But it's just an aesthetic flaw, and even
might have good side effects when it comes to debugging ("Can you
remember whether $bla was installed prior to your dist-upgrade?").
> I had to hack tetex-base so that it does not conflict with lmodern
> anymore, of course, and does not provide all the files that lmodern
> does. For the latter, I used remove-bad-license-files because it was the
> quickest way to get to the tests, but of course there is no license
> problem here.
[..]
> I simply wanted to be able to perform the tests with the new
> update-updmap and lmodern package implementing the new scheme. You'll
> probably want to redo the same modifications yourself, more cleanly (not
> using remove-bad-license-files in order to remove the lmodern files from
> tetex-base, for one).
Does that mean that you are willing to continue maintaining lmodern even
after teTeX 3.0 is out? This would be good news, especially because
lmodern will change much faster than tetex.
> As for update-updmap, I didn't really want to rebuild tetex-bin, so... I
> extracted the tetex-bin .deb I had already built, copied the new
> update-updmap in the extracted tree, modified the md5sums file in the
> control area and repacked the whole thing (if you do this at home
> [kids], beware of the owner/perms in your repacked .deb file before
> installing).
There's also a script, dpkg-repack or similar - it has been discussed on
-devel last week or the week before. By the way, if you have compiled
tetex-bin once and don't call the clean target, it is quite easy to make
changes to the packaging. In the 2.9 packages, it should be sufficient
to remove build-stamp (so that it compiles tetex-xwarn if necessary),
and you can even exchange the complete debian/ directory that way.
> tetex-base still contains /usr/share/texmf/dvips/config. I suppose it is
> done on purpose for backward compatibility.
>
> % ls -l /usr/share/texmf/dvips/config
> lrwxrwxrwx 1 root root 17 2004-12-21 02:10 /usr/share/texmf/dvips/config -> /etc/texmf//dvips
Yes, I was thinking of other font packages not moving their files fast
enough. But perhaps it would be the better approach to remove that link
and notify the maintainers - both by a mail and by the bug reports they
get.
> but does not fail, though. Also, please note the double "/" in the
> link's target.
Does that make any difference? It seemed to me not, so I didn't bother
to remove it.
> I used debian-fontmap-cfg to avoir potential clashes with future
> upstream directories... This is of course open to discussion... We could
> have a whole debian hierarchy under /var/lib/tetex but that would make
> things a bit deep.
/var/lib/tetex/debian-fontmap-cfg looks good to me.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: