Frank Küster <[EMAIL PROTECTED]> wrote: >>> If your old prerm fails, the new prerm should be called with >>> "failed-upgrade" as its first argument (see Policy 6.4 and 6.5), >>> so you can do any necessary workarounds there. Errors in postrm >>> are handled similarly. >> >> But what would be the "necessary workarounds"? The offending lines are: >> >> LOCALTEXMF=/usr/local/share/texmf >> rm -f $LOCALTEXMF/ls-R >> rmdir $LOCALTEXMF 2>/dev/null || true > > I was under the impression that "new-prerm failed-upgrade" was called > only to clean up after the failing old prerm script. But rereading 6.5, > I understand that the new prerm is called as a replacement for the > failed old prerm, and if it succeeds, the upgrade can proceed without > problems. Am I right?
I think I am right, but I still need further advice. There are two tetex source packages, tetex-base with the arch-independent stuff, and tetex-bin with the arch dependent stuff. Both only work together if the major versions match, and therefore tetex-base currently Conflicts: tetex-bin (<= 2.99.7), and on the other hand tetex-bin Depends: tetex-base (>= 3.0-4). Since there's no smooth way to update one after the other with these settings, apt usually removes tetex-base with --force-depends, then unpacks tetex-bin, then unpacks the new tetex-base and starts configuring. Now if the prerm script of tetex-base fails in this szenario, the new prerm is *not* called with failed-upgrade, because formally it is just a removal. Is there a way to tweak internal dependency relationships between -base and -bin to the effect that upon upgrade of a system that has both installed it is always tetex-bin that is removed with --force-depends? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer