Bug#299936: updmap.cfg, update-updmap and removed packages..

Hi,

I had an idea for a totally different approach to the problem that
removed packages leave their map files on the system, but must
deactivate them. I'm not yet convinced that it is better than what
Florent has designed, especially because I haven't completely written it
down yet - but if it works, it would have certain advantages.

The main advantage is the reason why I'm sending this to this bug
(Original title: updmap-sys --enable-map should act on 00updmap.cfg).
The problem in this bug is that according to upstream's documentation
(and, of course, many resources on the web and in newsgroups and mailing
lists) one can permanently enable map files with "updmap[-sys] --enable
[Mixed]Map=...". This edits updmap.cfg, and of course will be
overwritten by update-updmap every time this command is run.

In the original bug report, I suggested that we patch updmap-sys to act
on 00updmap.cfg instead. However, since map entries can be in different
files in updmap.d, it is unclear on which file in this directory it
should actually act. This is even more severe for --disable, which
would need to parse all cfg files in updmap.d. If people start
combining updmap-sys --enable with editing of files in that directory,
the outcome is even more complicated (there may be two entries for one
map file...).

Furthermore such a patch to updmap-sys will lead to further code
divergence from upstream, making maintenance of the code more
difficult.


Therefore I propose the following scheme:

updmap.cfg is a configuration file in /etc/texmf/. update-updmap does
not just concatenate the files in updmap.d; instead it parses them, and
acts on each Map line (I'm going to say Map in the following, the same
holds for MixedMap of course) in turn. Basically, it runs "updmap-sys
--enable Map=..." for every line, and writes the same information into a
file in /var/, let's call it fontmap.var. The purpose of this file is
to be able to compare the actual setting with the setting provided by
the previous conffile that has just been replaced.

Preservation of local configuration during upgrade or while a package is
removed works as follows:

1. For every map line in updmap.d/*.cfg, a line is written to
fontmap.var. The line indicates whether the corresponding package is
installed or removed, and what the setting is in the conffile in
updmap.d. Let's say there's a I for installed and a R for removed, a
whitespace and the line itself. In the case of R, an additional + or
- follows the R to indicate whether there was a discrepancy between
the conffile setting and the local setting.

2. If a package was purged and is now installed, update-updmap does not
find any information about the map lines in fontmap.var. Therefore

2.1) for "Map enabled.map" in updmapd.d/*.cfg it writes to fontmap.var

I Map enabled.map

and calls

updmap-sys --enable Map enabled.map

2.2) for "#! Map disabled.map" in updmapd.d/*.cfg it writes to fontmap.var

I #! Map disabled.map

and calls

updmap-sys --enable Map disabled.map # to add a line at all
updmap-sys --disable disabled.map # to disable it


3. If the user changes the settings in updmap.cfg, the next time
update-updmap acts on this Map line it notices that the setting is
different in fontmap.var and updmap.cfg and respects the setting in
updmap.cfg, i.e. it doesn't call updmap-sys --[en|dis]able.

4. If the conffile in updmap.d changes (either because the package
changes, or because the local admin changes it and runs
update-updmap) it goes like this:

4.1) conffile changes from enabled to disabled

4.1.1) setting in updmap.cfg and fontmap.var is enabled (i.e. no
local change): Change setting to disabled in both files

4.1.2) enabled in fontmap.var, disabled in updmap.cfg (i.e. local
change): Change setting to disabled in fontmap.var. Now all
three files have the same information, no problem in the
future

4.2) conffile changes from disabled to enabled

4.2.1) settings in updmap.cfg and fontmap.var are diabled (i.e. no
local change): Change setting to disabled in both files

4.2.2) disabled in fontmap.var, enabled in updmap.cfg (i.e. local
change): Change setting to enabled in fontmap.var. Now all
three files have the same information, no problem in the
future

5. If the file is removed, but not purged, updmap-sys is called with
--disable in all cases, but the current state in updmap.cfg is
written into fontmap.var, with R prepended instead of I. If this
means a change to the setting (i.e. there was a local change), R- is
written R+ otherwise.

6. If after removal the package is reinstalled

6.1) with a conffile setting now enabled:

6.1.1) setting in fontmap.var is

R+ #!...
(i.e. previously map file was disabled in conffile and
updmap.cfg, no local changes):

Enable in upmap.cfg and fontmap.var

6.1.2) setting in fontmap.var is

R- #!...
(i.e. previously map file was enabled in conffile but
disabled in updmap.cfg, local change):

Disable in upmap.cfg, enable in fontmap.var

6.1.3) setting in fontmap.var is

R+ Map...
(i.e. previously map file was enabled in conffile and
in updmap.cfg, no local change):

Enable in upmap.cfg and fontmap.var

6.1.3) setting in fontmap.var is

R- Map...
(i.e. previously map file was disabled in conffile but
enabled in updmap.cfg, local change):

Enable in upmap.cfg and fontmap.var

6.2) with a conffile setting now disabled:

6.2.1) setting in fontmap.var is

R+ #!...
(i.e. previously map file was disabled in conffile and
updmap.cfg, no local changes):

Disable in upmap.cfg and fontmap.var

6.2.2) setting in fontmap.var is

R- #!...
(i.e. previously map file was enabled in conffile but
disabled in updmap.cfg, local change):

Disable in upmap.cfg and fontmap.var

6.2.3) setting in fontmap.var is

R+ Map...
(i.e. previously map file was enabled in conffile and
in updmap.cfg, no local change):

Disable in upmap.cfg and fontmap.var

6.2.3) setting in fontmap.var is

R- Map...
(i.e. previously map file was disabled in conffile but
enabled in updmap.cfg, local change):

Enable in upmap.cfg, disable in fontmap.var


Uff. I think this would work.

It would get even nicer if we enhance updmap's --enable with a
--comment=".." option that writes the comment line before the Map line
- surely Thomas Esser would accept such a patch.

And it makes it trivial to swap map files between packages, they simply
don't care about settings in files in updmap.d, because the actual local
setting is always in updmap.cfg (or fontmap.var after a removal)

Good night...
Frank

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

Hi,

Frank Küster <frank.DeleteThis@kuesterei.ch> wrote:

> The main advantage is the reason why I'm sending this to this bug
> (Original title: updmap-sys --enable-map should act on 00updmap.cfg).
> The problem in this bug is that according to upstream's documentation
> (and, of course, many resources on the web and in newsgroups and mailing
> lists) one can permanently enable map files with "updmap[-sys] --enable
> [Mixed]Map=...".

But this is Debian here. We are better than that, you know.

> In the original bug report, I suggested that we patch updmap-sys to act
> on 00updmap.cfg instead. However, since map entries can be in different
> files in updmap.d, it is unclear on which file in this directory it
> should actually act. This is even more severe for --disable, which
> would need to parse all cfg files in updmap.d. If people start
> combining updmap-sys --enable with editing of files in that directory,
> the outcome is even more complicated (there may be two entries for one
> map file...).

Ack.

> Therefore I propose the following scheme:

[...]

> 2. If a package was purged and is now installed, update-updmap does not
> find any information about the map lines in fontmap.var. Therefore

So, when a font package is purged, it has to make sure that every map
line that is not in updmap.d/ is removed from fontmap.var.

[...]

> 3. If the user changes the settings in updmap.cfg, the next time
> update-updmap acts on this Map line it notices that the setting is
> different in fontmap.var and updmap.cfg and respects the setting in
> updmap.cfg, i.e. it doesn't call updmap-sys --[en|dis]able.

Changing a setting in updmap.cfg could also bring updmap.cfg in sync
with fontvar.map WRT this setting, and you would then infer that the
admin want to follow the config changes brought by the conffile in
updmap.d (whenever it is updated in the .deb), which is not necessarily
true...

> 4.1.2) enabled in fontmap.var, disabled in updmap.cfg (i.e. local
> change): Change setting to disabled in fontmap.var. Now all
> three files have the same information, no problem in the
> future

Here, the user wanted the map to be disabled. Since the pkg maintainer
happens to take the same decision at some point, the user's config will
now follow that of the .deb: reenabled whenever it is reenabled in the
..deb.

Of course, the same problem happens in general with conffiles. If you
happen to craft the exact same conffile as that distributed by the .deb
you have installed, then your config will follow that of the .deb in
next releases, unless there is a check on timestamps that I am not aware
of. But managing to craft the exact same conffile by sheer chance is in
general an exceptional event.

However, here, if a map was activated by default in a .deb you have
installed, and you later manually updmap-sys --disable then --enable it
(or simply enable it in the file under updmap.d/), you will have crafted
by "chance" the same config as shipped in the .deb and therefore, your
config will follow that of the .deb across releases, whether you like it
or not.

Similar thing for disabling, except that if you do it manually in
updmap.d/, you can use something else than #!, so that the system knows
that you really want the map disabled. However, if you run updmap-sys
--enable then --disable and the map was disabled as shipped in the .deb,
you have the same problem as in the previous paragraph.

> 4.2) conffile changes from disabled to enabled
>
> 4.2.1) settings in updmap.cfg and fontmap.var are diabled (i.e. no
> local change): Change setting to disabled in both files
^^^^^^^^
enabled, I suppose

> 4.2.2) disabled in fontmap.var, enabled in updmap.cfg (i.e. local
> change): Change setting to enabled in fontmap.var. Now all
> three files have the same information, no problem in the
> future

And your config will then follow the .deb, whether you like it or not...

[...]

> Uff. I think this would work.

Hmmm. You also have to deal with user additions to the files (possibly
user-added files) in updmap.d, somehow special-case 00updmap.cfg
(doesn't contain Map nor MixedMap lines; the options could be changed
there or in updmap.cfg directly, possibly conflicting) and with per-user
setups in $HOME...

I find all this rather complicated, but you may disagree.

--
Florent