Bug#403641: tetex-base: postrm fails if just unpackaged.
On Mon, Dec 18, 2006 at 06:33:21PM +0100, Frank Küster wrote:
> Kurt Roeckx <kurt@roeckx.be> wrote:
>
> > Package: tetex-base
> > Version: 3.0.dfsg.3-3
> > Severity: serious
> >
> > Hi,
> >
> > It seems that you can't uninstall the package if things aren't set up
> > properly.
>
> Hm, yes. What happens is:
>
> - tex-common is unpacked
Which contains the update-language that's being called, and
the /etc/texmf/language.d/00tex.cnf file it's trying to use.
> - tetex-base is unpacked
> - the install run fails because of an unrelated package
At this point, both tex-common and tetex-base are in unpacked but
not configure state. It looks like:
iU tetex-base 3.0.dfsg.3-3 Basic TeX input files of teTeX
iU tex-common 0.28 Common infrastructure for using and building
And dpkg created an /etc/texmf/language.d/00tex.cnf.dpkg-new,
there is no /etc/texmf/language.d/00tex.cnf yet.
> - the buildd tries to remove the packages it just installed.
>
> The postrm script of tetex-base assumes that it would be called with
> abort-install in this case, not "remove". However, I now see in policy
> that this is only used as error-unwind if the preinst fails.
>
> This problem might actually exist in more packages, since this paragraph
> from Policy:
>
> ,----
> | The Depends field should also be used if the postinst, prerm or postrm
> | scripts require the package to be present in order to run. Note,
> | however, that the postrm cannot rely on any non-essential packages to
> | be present during the purge phase.
> `----
>
> seems to imply that one *can* rely on Depended-on packages to be present
> *and*configured* at "postrm remove". Presense is actually guaranteed
> AFAICS, but configuredness not.
Yes, it says present and not configured or something, which atleast is
not what I expected.
> On the other hand, I'm not sure how to fix this. There's a reason why
> the update-* scripts fail (with an understandable error message) when
> the basic file is missing - so this shouldn't be changed. Should we
> really ignore all errors of update-* in "postrm remove"?
I currently don't have an idea what the proper thing to do is here, or
that this should be considered RC.
Kurt
Reply to: