Mike Hommey writes ("Re: Full install/removal/upgrade test results available"):
> On Mon, Dec 27, 2010 at 11:59:16PM +0000, Ian Jackson wrote:
> > So the problem is that python-xpcom does not work when it has been
> > previously installed, and then during an upgrade the new version has
> > been unpacked but not configured ?
>
> The remaining problem is that python-xpcom does not work when it was not
> previously installed but xulrunner-1.9.1 was.
Right.
> > If you add a dependency from xulrunner to python-xpcom this problem
> > ought to go away (although if that would lead to a circular dependency
> > the situation is more complicated as dpkg will need to break the
> > cycle).
>
> Plus, xulrunner doesn't need python-xpcom. The problem is that xulrunner
> trigger can't work when python-xpcom is only unpacked. It can only work
> after python-support trigger has run (or update-python-modules has been
> run from python-xpcom postinst, for that matter).
So what has happened is that python-xpcom registered something with
xulrunner, using a trigger mechanism. But the thing which
python-xpcom has registered is broken until python-xpcom is
configured ? So xulrunner's postinst, doing its trigger processing,
runs the python-xpcom hook, but the latter falls over due to lack of
configuration of python-xpcom ?
If so, that's a bug in python-xpcom. Any package which registers a
hook with another package must be prepared for its hook to be run even
when the registering package is not configured. If this is a problem,
arrangements should be made to arrange that the hook is a no-op when
in these circumstances and/or that it is run later when the
registering package is properly working.
For example, the hook could be registered only in python-xpcom's
postinst (and deregistered in its preinst).
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
