After a recent update and a depclean afterwards, lots of packages were left with broken symlinks to python-exec in /usr/bin. Apparently they still needed python-exec:0, but had no direct dependency on it. The affected packages were: app-backup/duplicity-0.6.22 app-portage/layman-2.0.0 app-portage/mirrorselect-2.2.0.1 dev-java/java-config-2.2.0 dev-python/couchdb-python-0.9 dev-python/docutils-0.10 dev-python/numpy-1.7.1 dev-python/pip-1.4.1 dev-python/pygments-1.6 dev-python/subvertpy-0.9.1 dev-python/urlgrabber-3.9.1-r2 dev-util/scons-2.3.0 dev-vcs/bzr-2.5.1-r1 gnome-base/gconf-3.2.6-r1 kde-base/pykde4-4.11.2-r1 media-gfx/uniconvertor-1.1.5-r1 net-misc/electrum-1.8.1 Reproducible: Always
dev-python/python-exec was at 0.3.1 and now is at 2.0-r1
can confirm this. remerging the broken packages will updating the symlink
(In reply to lukas elsner from comment #2) > can confirm this. remerging the broken packages will updating the symlink Command that might help you with that: q file --quiet --nocolor `find -L /usr/bin -type l` | sort --unique
Typing this, will make you happy in one line! ;) emerge -av `q file --quiet --nocolor \`find -L /usr/bin -type l\` | sort --unique`
(In reply to lukas elsner from comment #2) > can confirm this. remerging the broken packages will updating the symlink Does not work here for all packages: >>> Installing (17 of 17) kde-base/pykde4-4.11.2-r1 * QA Notice: Symbolic link /usr/bin/pykdeuic4 points to /usr/bin/python-exec which does not exist. ls on /usr/bin/pykdeuic4 confirms that the symlink is broken: $ ls -l /usr/bin/pykdeuic4 lrwxrwxrwx 1 root root 11 Oct 26 12:57 /usr/bin/pykdeuic4 -> python-exec
forgot the oneshot, sorry! emerge -1av `q file --quiet --nocolor \`find -L /usr/bin -type l\` | sort --unique`
I wonder why those packages didn't have a dep on python-exec for you... looking at the few random ebuilds, it seems they should have one. Do you have any system where you didn't rebuild them to confirm?
(In reply to Michał Górny from comment #7) > I wonder why those packages didn't have a dep on python-exec for you... > looking at the few random ebuilds, it seems they should have one. Do you > have any system where you didn't rebuild them to confirm? On a system that's still on python-exec:0, I have this: $ grep python-exec /var/db/pkg/dev-python/docutils-0.10/*DEP* /var/db/pkg/dev-python/docutils-0.10/DEPEND: ... dev-python/python-exec[python_targets_python2_7(-),python_targets_python3_2(-),-python_single_target_python2_5(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-),-python_single_target_python3_1(-),-python_single_target_python3_2(-),-python_single_target_python3_3(-),-python_single_target_pypy1_9(-),-python_single_target_pypy2_0(-)] /var/db/pkg/dev-python/docutils-0.10/RDEPEND: ... dev-python/python-exec[python_targets_python2_7(-),python_targets_python3_2(-),-python_single_target_python2_5(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-),-python_single_target_python3_1(-),-python_single_target_python3_2(-),-python_single_target_python3_3(-),-python_single_target_pypy1_9(-),-python_single_target_pypy2_0(-)] That package was emerged on 26 Jun 2013... The ebuild itself has no dependency on python-exec so I assume it comes from an eclass. Could it be that packages emerged before distutils-r1.eclass rev 1.79 or so have this unslotted dependency? In my main system, re-emerging the problem packages fixed all but kde-base/pykde4-4.11.2-r1 - there the explicit dependency on :0 was added to the 4.11.1 version but not the 4.11.2 version added to the tree later.
(In reply to Jouni Kosonen from comment #8) > (In reply to Michał Górny from comment #7) > > I wonder why those packages didn't have a dep on python-exec for you... > > looking at the few random ebuilds, it seems they should have one. Do you > > have any system where you didn't rebuild them to confirm? > > Could it be that packages emerged before distutils-r1.eclass rev 1.79 or so > have this unslotted dependency? This is true but emerge of dev-python/python-exec-2.0-r1 should fix all the dependencies of installed packages. There should be a 'Fixing unslotted python-exec dependencies in installed packages' messages after the install.
(In reply to Michał Górny from comment #9) > This is true but emerge of dev-python/python-exec-2.0-r1 should fix all the > dependencies of installed packages. There should be a 'Fixing unslotted > python-exec dependencies in installed packages' messages after the install. There is, this was logged in the main machine: >>> Original instance of package unmerged safely. * Fixing unslotted python-exec dependencies in installed packages ... [ ok ] >>> dev-python/python-exec-2.0-r1 merged. Still the python-exec:0 ended up on depclean there. The other machine is on the stable tree, and emerging python-exec:2 there would apparently trigger a rebuild of libreoffice among other things - not going to do that now.
Well, I have committed a -r2 that passes 'g' option to sed to make sure that all references to python-exec are fixed. I have no idea if this would change anything at all but it's worth a try. Please sync the tree, install python-exec-2.0-r2 and tell me if it fixed some more packages.
I keyworded and emerged python-exec-2.0-r2 on the other machine. It did rewrite all instances of "dev-python/python-exec[" to "dev-python/python-exec:0[" and thus prevented depleaning of :0. It also triggered an immediate rebuild of at least most of the affected packages which ends up making them depend on dev-python/python-exec:2/2= instead - this definitely did not happen on the main machine. Could it simply be that the 2.0-r1 there was v1.1 from before this commit: 07 Oct 2013; Michał Górny <mgorny@gentoo.org> python-exec-2.0-r1.ebuild, python-exec-2.9999.ebuild: Touch vardb after modifications as suggested by Arfrever. and the modified deps weren't noticed by portage?
(In reply to Jouni Kosonen from comment #12) > I keyworded and emerged python-exec-2.0-r2 on the other machine. > > It did rewrite all instances of "dev-python/python-exec[" to > "dev-python/python-exec:0[" and thus prevented depleaning of :0. Great, thanks for checking this. I will consider the bug FIXED then. Feel free to reopen if the issue persists. > It also triggered an immediate rebuild of at least most of the affected > packages which ends up making them depend on dev-python/python-exec:2/2= > instead - this definitely did not happen on the main machine. That's probably because you rebuilt them earlier. The eclass starting v1.61 sets deps that cause rebuilds when slot of python-exec changes, at least with the default configuration of portage. If you want to delay that, you can use '--rebuild-if-new-slot n' safely. > Could it simply be that the 2.0-r1 there was v1.1 from before this commit: > > 07 Oct 2013; Michał Górny <mgorny@gentoo.org> python-exec-2.0-r1.ebuild, > python-exec-2.9999.ebuild: > Touch vardb after modifications as suggested by Arfrever. > > and the modified deps weren't noticed by portage? Hmm, you may be right. I should've revbumped it then. Sorry.
Not fixed. The following packages just broke for me due to stale symlinks to /usr/bin/python-exec: app-portage/flaggie app-portage/gentoolkit-dev app-portage/gentoopm app-portage/layman app-text/gnome-doc-utils dev-java/java-config dev-python/cython dev-python/docutils dev-python/docutils-glep dev-python/numpy dev-python/pygments dev-python/pyrex dev-util/gdbus-codegen dev-util/scons dev-vcs/bzr gnome-base/gconf gnome-extra/gnome-games media-gfx/uniconvertor Reopening and increasing severity.
*** Bug 489692 has been marked as a duplicate of this bug. ***
*** Bug 489740 has been marked as a duplicate of this bug. ***
Ok, I've just committed the largest work-around possible ATM. Now there's 2.0-r1, -r2 and -r3 that all PDEP on python-exec:0. This way, if emerge's dynamic-deps work, all people having the older versions will get the PDEP immediately. Other people will get it via revbump/upgrade. Since this way we lose the ability to judge whether the vdb hack worked, I'd appreciate some help debugging it. @ulm, since you have a broken system, can I ask you to check vardb *DEPEND entries of the mentioned packages? Did you install 2.0-r2 before running the --depclean?
(In reply to Michał Górny from comment #18) > Since this way we lose the ability to judge whether the vdb hack worked, > I'd appreciate some help debugging it. @ulm, since you have a broken system, > can I ask you to check vardb *DEPEND entries of the mentioned packages? The above-mentioned files contain a dependency on dev-python/python-exec:0 and have a newer timestamp than the others in their directory. Nevertheless, python-exec:0 was depcleaned. > Did you install 2.0-r2 before running the --depclean? Yes. I did emerge --sync today around 7:00 UTC, then update and depclean. <QA hat> You shouldn't pursue the VDB hack further. Accessing the VDB from within an ebuild is a horrible QA violation. </QA hat>
Ok, here's my best idea so far. Please tell me if you think I'm missing some case. 1. We "move" the real python-exec to a new category, like sys-apps/python-exec. There we put both slots, without any hacks. The new ebuilds block current versions of dev-python/python-exec. 2. We add a new versions of dev-python/python-exec:{0,2} that are purely virtual ebuilds that pull in *both* sys-apps/python-exec:0 and :2. 3. We make the eclasses and ebuilds pull in sys-apps/python-exec:=. So, the idea would be specifically that: 1. People will seamlessly get dev-python/python-exec executables replaced with new sys-apps/python-exec. 2. Packages that are built from now on will have proper deps on sys-apps/python-exec. 3. Packages that were built in the past will pull in either virtual slot, resulting in both versions of python-exec being around for the sake of safety. With this solution, no breakage should happen and people would be able to depclean old python-exec at the proper time. Please let me know if you're ok with that solution.
If I understood you correctly, installed packages will pull the 'virtual' package dev-python/python-exec, while newer installations will depend on sys-apps/python-exec. Right ? In that case: I like your approach :)
(In reply to Michał Górny from comment #20) It seems ok to me.
Hmm so do I understand correctly that the python-r1 eclass used to have a dep "dev-python/python-exec" and now that you changed it to "dev-python/python-exec:=" it doesn't help stuff that's already installed? If yes, is such behavior correct per PMS, and if yes shouldn't it be changed to reflect in-tree changes in deps for installed ebuilds? (I really thought that it used to be the case that available ebuilds override installed ones wrt deps) In such case your solution should work I guess. But I'd hate it to become the only viable solution for such cases.
*** Bug 489806 has been marked as a duplicate of this bug. ***
*** Bug 489834 has been marked as a duplicate of this bug. ***
Should be fixed now via the package 'move'.
