Frank Küster <[EMAIL PROTECTED]> wrote: > Maybe we have a design flaw here in our updmap-magic scheme. Just that > it should have revealed itself earlier.
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 conffiles > 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. -- Florent