Re: Policy, updmap --enable and updmap.cfg in /etc or /var

[Florent Rougon <f.rougon@free.fr>]

Frank Küster <frank@debian.org> wrote:

> I don't have much time and would like to look at this later. Just a

Same for me for your tetex-beta packages. :)

> quick question: The problems you mention come from the combination of
> ucf and the /var/lib/lmodern mechanism, don't they?

Not really. You have this problem whenever transitioning a config file
to ucf. If ucf is not aware of a config file, when you call it for the
first time for this file, it will create the config file by copying the
default version shipped in you package, i.e., it will act just as cp,
with a message telling that he created the file:

Creating config file /etc/texmf/updmap.d/10lmodern.cfg with new version

This is a problem whenever you are transitioning a file to ucf and his
possible deletion before the upgrade to the first ucf-aware version of
your package has to be preserved (here, if the admin deleted
10lmodern.cfg, we don't want ucf to magically recreate it).

The workaround is to store (in a file under $STATE_DIR) that we are in
the precise case of an upgrade between a non-ucf-aware version and a
ucf-aware version of the package, and that the config file has been
deleted, meaning that ucf will create it, which is not desired. After
ucf has created it (and therefore, registered the config file, which is
the whole point of calling ucf in this case), I check whether the file
under $STATE_DIR is present and, if this is the case, I remove the
wrongly-created config file, and then the file that was created under
$STATE_DIR since we don't need it anymore, since the config file is now
registered with ucf, so it won't recreate it on future upgrades.

Creating a file under $STATE_DIR just for that is, well, not extremely
elegant, but it allows the script to remain idempotent, which wouldn't
be possible with a shell variable...

> The /var/lib/lmodern mechanism itself does work as before, right?

Yes, the previous logic is all still there. There is just a bit more
code to work around the aforementioned problem. :-)

(if you want to see the discussion of the problem with Manoj when you
have more time, and in particular why I think that this workaround is
the best solution without important changes to ucf, see bug #279259)

-- 
Florent