Bug#420390: Purging tetex transition packages removes texlive configuration files
[ writing this in the train, no idea when I'll be able to actually send
this mail to the world - so the info might be outdated]
Frans Pop <elendil@planet.nl> wrote:
> Part of the problems discussed there can be traced to this BR: the fact
> that some essential configuration files had gone missing.
> Important here is that at some point I decided to *purge* the old tetex
> transition packages (which is a completely valid action).
>
> The problem seems to be that the "ownership" of some config files is not
> transfered from the old tetex packages (now empty transition packages) to
> the corresponding texlive packages.
The basic problem is that tetex-base's postrm (from etch, upon purge)
does some cleanup of files which were in /etc/texmf in woody and sarge
and are useless now. But as it turns out, some have now been
resurrected and are of vital importance in lenny.
I think the solution would be to create a package tetex-base_2007-* from
texlive-base-bin and give it a sane postrm - after that it can safely be
purged.
Either this postrm just does nothing: We will be sure it does no harm,
but users who have this old cruft lying around have no automatic way to
move it out of the way.
Or we write a postrm which does the cleanup, but leaves out the things
it shouldn't do. I've written something like this, based on the postrm
of tetex-base in etch. One thing that I wondered while looking at the
code: It always removes the files from TDS locations in /etc/texmf, not
from their old locations. For example, it removes
/etc/texmf/metafont/misc/modes.mf, not /etc/texmf/modes.mf. To me it
seems, it should at least *also* remove the old ones. Maybe this is
actually the cleanup after some version early in etch's release cycle
which moved those files to TDS locations? Having no network access, I
can't check the CVS or SVN logs.
If we go that way and do the cleanup, we should test different upgrade
scenarios. I still have tar.gz around for woody and sarge chroots, so I
could in principle do that:
1. Install tetex-extra in etch, upgrade
2. Install tetex-extra in sarge, upgrade to etch and to sid
3. Same, start with woody
4. Install tetex-extra in woody, remove but keep tetex-bin, upgrade to
sarge, install tetex-extra again, upgrade to etch and sid
5. Like 4., but install tetex-extra only after upgrading to etch
6. Like 5., but start with sarge
and whatever weird combinations one can imagine. Note that the scenario
4 (or was it 5?) actually was reported by a user and prompted a lot of
the cleanup code we have.
> The following files are present after B, but not after A:
> /etc/texmf/dvipdfm/config/dvipdfmx.cfg (maybe)
dvipdfmx.cfg is *not* handled by any of the tetexens' postrm scripts.
> /etc/texmf/dvips/config/config.ps
this is removed by tetex-base
> /etc/texmf/fmt.d/01tetex.cnf (maybe)
Didn't look at this - it's good when it's gone and maybe it's a texlive
package which removes it.
> /etc/texmf/metafont/misc/modes.mf
> /etc/texmf/tex/generic/config/pdftexconfig.tex
> /etc/texmf/tex/latex/config/color.cfg
> /etc/texmf/tex/latex/config/graphics.cfg
> /etc/texmf/tex/latex/config/hyperref.cfg
These are all covered by my analysis and handled by tetex-base
> /etc/texmf/web2c/mktex.cnf
mktex.cnf is *not* handled by any of the tetexens' maintainer scripts.
I'm puzzled how that could vanish.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: