[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: