Bug#606791: Full install/removal/upgrade test results available

[Ian Jackson]

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.