On Mon, Dec 27, 2010 at 11:59:16PM +0000, Ian Jackson wrote:
> Mike Hommey writes ("Re: Full install/removal/upgrade test results
> available"):
> > Unfortunately, while some cases were fixed, the original case for which
> > the pre-depends was added fails again :(
> >
> > (starting from xulrunner-1.9.1 already installed, and installing
> > python-xpcom, case which I forgot to test before my last uploads)
> > Unpacking python-xpcom (from
> > .../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ...
> > Processing triggers for xulrunner-1.9.1 ...
> > Obtaining the module object from Python failed.
> >
> > <type 'exceptions.ImportError'>: No module named xpcom.server
> > Obtaining the module object from Python failed.
>
> 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).
The root of the problem, really, is that python packages can't be used
when only simply unpacked.
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101228072824.ga3...@glandium.org
