Comment 17 for bug 19894

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 03 Aug 2005 13:01:10 +0200
From: Florent Rougon <email address hidden>
To: Christoph Bier <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#320980: [Christoph Bier] Re: Bug#320980: tetex-bin: Updmap
 error because a map file has not been found

Frank K=FCster <email address hidden> wrote:

> Maybe we have a design flaw here in our updmap-magic scheme. Just that
> it should have revealed itself earlier. =20

Nope. :)

> Here, tetex-base, tetex-bin and tetex-extra are upgraded in the same
> apt-get run, and they are configured in the order tetex-base, tetex-bin=
,
> tetex-extra. Therefore, when tetex-bin is configured, the new conffile=
s
> of tetex-extra are still named $conffile.dpkg-new, but the files in
> /var/lib/tex-common/* are already there. No wonder updmap cannot find
> $conffile; but why didn't this ocurr earlier?

If $conffile is a conffile, since our Policy recommends .cfg files in
/etc/texmf/updmap.d to also be conffiles, $conffile and the conffile in
/etc/texmf/updmap.d that declares it should be simultaneously existent
or non-existent whenever update-updmap is run (because they should be
shipped in the same .deb).

Therefore, if both files are still at the .dpkg-new state and
update-updmap is run (e.g., in your previous scenario, the files are
shipped by tetex-extra and tetex-bin is being configured---I am not even
sure the files would still be at .dpkg-new state, but anyway), the final
map files will get for this particular map the *old* configuration. No
problem. When tetex-extra is itself configured, the files are not at
.dpkg-new state anymore and the final configuration ends up in the final
map files.

Maybe if you manage files in /etc/texmf/updmap.d with ucf, problems can
arise... I didn't consider this scenario.

--=20
Florent