Hi,
Frank Küster <[EMAIL PROTECTED]> 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
