Re: Full install/removal/upgrade test results available
On Wed, Dec 29, 2010 at 12:50:06PM +0000, Ian Jackson wrote:
> 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.
> > > 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 ?
xulrunner has a file trigger for components in
/usr/lib/xulrunner-1.9.1/components, so that it registers them in
compreg.dat and xpti.dat. This means it has to load the components to
get their registration information. But the components python-xpcom adds
need the python modules to be registered to work, which means xulrunner
component registration need to happen after python-xpcom's modules are
available, which usually only happens after python-support's trigger,
but in python-xpcom case, it's forced to run during its postinst, which
is unfortunately still too late.