Bug#299936: updmap.cfg, update-updmap and removed packages: Yet an other approach
Florent Rougon <f.rougon@free.fr> wrote:
> Hi,
>
> Frank Küster <frank@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. :)
But it's in the docs, mailing lists, README files, and people will try
it.
>> 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.
Ups, yes, this is a little difficult, since the file in updmap.d is
gone. I hope we don't end up in rewriting updmap...
>> 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...
Well, yes. If the package's choice was "enable", the local choice was
first "disable" and then "enable" again, and now the package decides
"disable", it would be disabled. But often there is a reason why a
package changes settings (like no longer shipping the font, but still
offering sample Map lines for the people who keep it or buy it). And
anyway, this is exactly the same as if updmap.cfg was managed by dpkg:
If the file is unchanged compared to the last packaged version, the
changed version from the new package will be used, regardless whether
the admin ever touched it.
> 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.
That's a good point.
> I find all this rather complicated, but you may disagree. :)
Indeed it is. On the other hand, patching updmap --enable/disable to
work on Debian isn't less complicated, I fear. The only really easy
thing to do would be to change --enable/disable to just echo some
"please use update-updmap" message on stderr, and then do nothing.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: