Re: [Help] How to fix a buggy prerm script in sarge?
Frank Küster <frank@debian.org> 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
Reply to: