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

Another way to deal with the Font Map Problem



Hi,

Up until now, I've tried to find a good, policy-compliant way to deal
with the problems posed by files such as
/etc/texmf/updmap.d/10lmodern.cfg. The first solution was acceptable in
most respects but didn't allow for updating the file by the maintainer
as can be done with conffiles. More recently, I added ucf support to an
experimental version of lmodern to solve this problem. The last possible
race I spotted forced me to add yet another state file under
/var/lib/lmodern/ to ensure that the maintainer scripts do what they
should do, can be cancelled unattended and remain idempotent next time
they are run.

I found that a bit too much, so I didn't ask my sponsor to upload the
package. I filed bug #282963 against ucf, requesting a feature that
would make the last problem vanish.

However, another solution occured to me that could solve all these
problems in a relatively nice way, allowing for easy packaging of fonts,
AFAICS. Instead of trying to bend font packages in such a way that they
work safely with the current tools, we could make a slight modification
to update-updmap and add simple a tool for use by font package
maintainer scripts only, which would allow the fine .cfg files to be
actual conffiles.

Simply, we would have a file such as
/var/lib/tetex/disabled-fontmap-cfg-files looking like that:

,----
| 10foo
| 10lmodern
| 10bar
| 10quux
`----

update-updmap would work just as usual, except that it would ommit the
files whose base names are listed in that file.

We would provide a small tool such as dtetex-manage-fontmap-cfg-files[1]
that would be called:
  - in the postinst of font packages, to make sure their .cfg files are
    not listed anymore in disabled-fontmap-cfg-files (otherwise,
    update-updmap would ignore them);
  - in the postrm of font packages, to add the relevant .cfg files to
    disabled-fontmap-cfg-files [perhaps also to remove them if the
    package is purged in order to clean up the file, if we are *sure*
    that the .cfg conffiles will be removed by dpkg; I don't think this
    is guaranteed in all cases, so maybe we wouldn't do that].

The .cfg files would be real conffiles: users could modify them, delete
them, whatever, and package maintainers could ship updated versions in
their .deb files. Yeah.

The biggest downside I can see for the moment is that
/etc/texmf/updmap.d/ would contain, for removed-but-not-purged font
packages, files that are ignored by update-updmap. This might be a
little confusing. I don't think it is much, however. What's the deal?
Users scared of including map files for fonts that have gone? If this
happens to be the case, they will delete the relevant .cfg files or
comment the Map or MixedMap lines in them. That will have no effect
whatsoever since update-updmap would be ignoring the .cfg files for such
packages, but they will feel safe. :)
Of course, we would document this detail in update-updmap's manpage.

If you think this scheme is a good idea, I'm willing to implement and
document it (post-sarge).

Comments, flames? :-)


  [1] dtetex 'cause it is not something that belongs to teTeX, but is a
      Debian addition which moreover should only be used in package
      maintainer scripts...

-- 
Florent



Reply to: