Bug#606791: Full install/removal/upgrade test results available
Mike Hommey writes (Re: Full install/removal/upgrade test results available): On Mon, Dec 27, 2010 at 11:59:16PM +, 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
Bug#606791: Full install/removal/upgrade test results available
Le mercredi 29 décembre 2010 à 12:50 +, Ian Jackson a écrit : 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). This is what I have already proposed to Mike on IRC: moving libpyloader.so to a different directory and setting it as a symlink in python-xpcom.postinst. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
On Wed, Dec 29, 2010 at 01:52:13PM +0100, Josselin Mouette wrote: Le mercredi 29 décembre 2010 à 12:50 +, Ian Jackson a écrit : 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). This is what I have already proposed to Mike on IRC: moving libpyloader.so to a different directory and setting it as a symlink in python-xpcom.postinst. Which would also mean firing dpkg-trigger in python-xpcom.postinst, too. This all looks like overcomplication to circumvent an imho design flaw in python packages. Unfortunately, except if I drop python-support use entirely (which could even mean going against the python policy, but I don't remember the details of it wrt modules location), there's nothing else I can do. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
On Wed, Dec 29, 2010 at 12:50:06PM +, Ian Jackson wrote: Mike Hommey writes (Re: Full install/removal/upgrade test results available): On Mon, Dec 27, 2010 at 11:59:16PM +, 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 ? 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. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
Le mercredi 29 décembre 2010 à 14:14 +0100, Mike Hommey a écrit : Which would also mean firing dpkg-trigger in python-xpcom.postinst, too. This all looks like overcomplication to circumvent an imho design flaw in python packages. Call it a design flaw, but no package is expected to actually work before its postinst has been executed. That is the policy. Unfortunately, except if I drop python-support use entirely (which could even mean going against the python policy, but I don't remember the details of it wrt modules location), there's nothing else I can do. You can use dh_python2 which does what you want, but AFAIK it’s not the recommended tool for squeeze. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
Le mercredi 29 décembre 2010 à 14:19 +0100, Mike Hommey a écrit : 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. Note that in the python-xpcom case, it is useless to force update-python-modules -p in the postinst. The symlinks are installed by the postinst and are sufficient for anything that needs the modules. The trigger is here for byte-compilation. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
On Mon, Dec 27, 2010 at 11:59:16PM +, 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote: Le mardi 21 décembre 2010 à 20:59 +0100, Mike Hommey a écrit : Adding update-python-modules -p in python-xpcom postinst could make things slightly better, but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. What if xulrunner-1.9.1's postinst would do nothing for configure ? would the trigger still kick in when one installs xulrunner-1.9.1 only? You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. 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. type 'exceptions.ImportError': No module named xpcom.server Setting up libncursesw5 (5.7+20100313-4) ... Setting up libssl0.9.8 (0.9.8o-4) ... Setting up mime-support (3.51-1) ... update-alternatives: using /usr/bin/see to provide /usr/bin/view (view) in auto mode. Setting up python2.6-minimal (2.6.6-8+b1) ... Setting up python2.6 (2.6.6-8+b1) ... Setting up python-minimal (2.6.6-3+squeeze4) ... Setting up python (2.6.6-3+squeeze4) ... Setting up python-support (1.0.11) ... Setting up libpython2.6 (2.6.6-8+b1) ... Setting up python-xpcom (1:0.0~hg20100212-3) ... Processing triggers for python-support ... Yes, the xulrunner-1.9.1 trigger happens right after unpack... before python-xpcom's postinst g. I'm starting to hate dpkg triggers. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
Le lundi 27 décembre 2010 à 18:57 +0100, Mike Hommey a écrit : On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote: You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( Yes, the xulrunner-1.9.1 trigger happens right after unpack... before python-xpcom's postinst g. I'm starting to hate dpkg triggers. Maybe you want dpkg-trigger --no-await ? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#606791: Full install/removal/upgrade test results available
On Mon, Dec 27, 2010 at 09:08:14PM +0100, Josselin Mouette wrote: Le lundi 27 décembre 2010 à 18:57 +0100, Mike Hommey a écrit : On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote: You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( Yes, the xulrunner-1.9.1 trigger happens right after unpack... before python-xpcom's postinst g. I'm starting to hate dpkg triggers. Maybe you want dpkg-trigger --no-await ? Point is, xulrunner is already installed, thus its postinst is not what triggers. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
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 ? 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). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
Le mardi 21 décembre 2010 à 20:59 +0100, Mike Hommey a écrit : Adding update-python-modules -p in python-xpcom postinst could make things slightly better, but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. What if xulrunner-1.9.1's postinst would do nothing for configure ? would the trigger still kick in when one installs xulrunner-1.9.1 only? You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#606791: Full install/removal/upgrade test results available
* Mike Hommey m...@glandium.org, 2010-11-19, 09:18:
Mike Hommey gland...@debian.org
python-xpcom (U)
I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1.
Indeed.
OTOH, the pre-depends solves a part of another problem though not
entirely, due to triggers ordering: the xulrunner-1.9.1 trigger can't
work until the python-support trigger has been run...
I don't see how pre-depends could have helped here. On the first glance
it makes it only worse. E.g., when I install python-xpcom in a clean
chroot I get:
| Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-2_i386.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.
|
| type 'exceptions.ImportError': No module named xpcom.server
When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
everything was registered just fine.
The only fix for that issue that I can think of would be to stop using
python-support... If other people have ideas, I'm all ears.
I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
postinst if it's not already registered. See the attached patch (well,
except maybe xulrunner version shouldn't be hardcoded).
--
Jakub Wilk
diff -u pyxpcom-0.0~hg20100212/debian/control pyxpcom-0.0~hg20100212/debian/control
--- pyxpcom-0.0~hg20100212/debian/control
+++ pyxpcom-0.0~hg20100212/debian/control
@@ -18,8 +18,8 @@
Provides: ${python:Provides}
Depends: ${shlibs:Depends},
${misc:Depends},
- ${python:Depends}
-Pre-Depends: ${xulrunner:Depends}
+ ${python:Depends},
+ ${xulrunner:Depends}
Breaks: epiphany-gecko ( 2.28)
XB-Python-Version: ${python:Versions}
Description: XPCOM bindings for Python
diff -u pyxpcom-0.0~hg20100212/debian/postinst pyxpcom-0.0~hg20100212/debian/postinst
--- pyxpcom-0.0~hg20100212/debian/postinst
+++ pyxpcom-0.0~hg20100212/debian/postinst
@@ -9,2 +9,7 @@
+if ! grep -F '@mozilla.org/module-loader/python;' /usr/lib/xulrunner-1.9.1/components/compreg.dat /dev/null
+then
+ dpkg-trigger /usr/lib/xulrunner-1.9.1/components
+fi
+
#DEBHELPER#
Bug#606791: Full install/removal/upgrade test results available
On Tue, Dec 21, 2010 at 08:37:53PM +0100, Jakub Wilk wrote:
* Mike Hommey m...@glandium.org, 2010-11-19, 09:18:
Mike Hommey gland...@debian.org
python-xpcom (U)
I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1.
Indeed.
OTOH, the pre-depends solves a part of another problem though not
entirely, due to triggers ordering: the xulrunner-1.9.1 trigger
can't work until the python-support trigger has been run...
I don't see how pre-depends could have helped here.
I don't remember the details, but it made things half better.
On the first
glance it makes it only worse. E.g., when I install python-xpcom in
a clean chroot I get:
| Unpacking python-xpcom (from
.../python-xpcom_1%3a0.0~hg20100212-2_i386.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.
|
| type 'exceptions.ImportError': No module named xpcom.server
When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
everything was registered just fine.
The only fix for that issue that I can think of would be to stop
using python-support... If other people have ideas, I'm all ears.
I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
postinst if it's not already registered. See the attached patch
(well, except maybe xulrunner version shouldn't be hardcoded).
I'd expect that to fail as well, because of python-support trigger not
having been run yet.
Part of the problem is that the xulrunner-1.9.1's postinst or trigger can
run with python-xpcom unpacked but not registered with python-support.
Adding update-python-modules -p in python-xpcom postinst could make
things slightly better, but that would still leave xulrunner-1.9.1's
postinst complaining if it's run before python-xpcom's.
What if xulrunner-1.9.1's postinst would do nothing for configure ?
would the trigger still kick in when one installs xulrunner-1.9.1 only?
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
* Mike Hommey m...@glandium.org, 2010-12-21, 20:59: I think you could manually trigger xulrunner-1.9.1 in python-xpcom's postinst if it's not already registered. See the attached patch (well, except maybe xulrunner version shouldn't be hardcoded). I'd expect that to fail as well, because of python-support trigger not having been run yet. Part of the problem is that the xulrunner-1.9.1's postinst or trigger can run with python-xpcom unpacked but not registered with python-support. Adding update-python-modules -p in python-xpcom postinst could make things slightly better, update-python-modules -p is already in python-xpcom's postinst and it does exactly what python-support trigger would do. but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. Unfortunately, this is true. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606791: Full install/removal/upgrade test results available
On Tue, Dec 21, 2010 at 09:41:54PM +0100, Jakub Wilk wrote: * Mike Hommey m...@glandium.org, 2010-12-21, 20:59: I think you could manually trigger xulrunner-1.9.1 in python-xpcom's postinst if it's not already registered. See the attached patch (well, except maybe xulrunner version shouldn't be hardcoded). I'd expect that to fail as well, because of python-support trigger not having been run yet. Part of the problem is that the xulrunner-1.9.1's postinst or trigger can run with python-xpcom unpacked but not registered with python-support. Adding update-python-modules -p in python-xpcom postinst could make things slightly better, update-python-modules -p is already in python-xpcom's postinst and it does exactly what python-support trigger would do. Which I must have added in an attempt to fix the issue, so it's possibly not enough. but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. Unfortunately, this is true. But then, it's only noise, which is still better than a failure to upgrade. So in the worst case scenario where we don't find anything better, and if we are sure it doesn't break any other case, we could just remove the pre-depend and be done with it. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
