Due to the ongoing life of bug #11359, most people will never see the enotice to run python-updater. Since there is an externally documented method of rebuilding stuff that was affected by a library build, namely revdep-rebuild, I propose calling python-updater from revdep-rebuild. See also bug #73932 for a perl version of this. Here starts my campaign to get everything added to revdep-rebuild. Reproducible: Always Steps to Reproduce: 1. emerge an old version of python 2. emerge world 3. nobody sees the enotice to run python-updater Actual Results: Things were mysteriously broken. Expected Results: The script used to clean up after the python upgrade should have been called from revdep-rebuild. The revdep-rebuild tool is documented in the gentoolkit section (and many other places), so many (most? all?) people should be running it on a regular basis anyway. The python cleanup script should use the same command options as revdep-rebuild. This has been distilled from bugs #68848 and #68859. It is similar to bug #73932.
*** Bug 68859 has been marked as a duplicate of this bug. ***
python herd, what are your thoughts on this? I am very hesitant to add this type of functionality when python-updater is not installed to /usr/bin or /usr/sbin
hrmm, python-updater is in /usr/sbin .. i'm not opposed to this, but i'd rather see a more concerted effort to making a generic tool to clean up after portage, or if not, all some api to control portage from within an ebuild. all these tools such as revdep-rebuild and python-updater were designed as temporary solutions until portage gets reverse dependencies. since that is still quite far off from the looks of things, maybe we should have a nice framework for devs to signal things might need rebuilding. (btw, i apologise if i under-estimated the reverse dependency capabilities of portage-ng, i have no experience on that at all. please correct me if i'm wrong)
Your're right it is in /usr/sbin. I think when I went looking, I looked for python_updater instead (/me feels stupid). As far as moving forward, I still see all of these tools as temporary. However, since we are still aways off from portage-2.1 with reverse dependency checking built in, I would like to spend the time to make these tools as simple, robust, and dependable as possible. This is for two reasons, no one likes a broken system, and it gives us practical experience on what will need to be handled by portage when the time comes for it to be integrated. As far as integrating, my current plan would be to add a --python flag to revdep-rebuild which just serves as a wrapper to python-updater.
>However, since we are still aways off from portage-2.1 with reverse dependency checking built in I was under the assuption that this wouldn't be a feature for Portage 2.1!? Counting the number of incorrect or incorrectly stored dependencies in ebuilds, I'd say we're way off to see proper reverse dependency checking.
That was supposed to be portage 2.1+ (meaning whichever version beyond the current 2.0). Currently the roadmap at http://dev.gentoo.org/~jstubbs/docs/roadmap.html lists it as a 2.2 feature. Regardless, my point still stands.
2.1 has some new logging features courtesy of genone that should help with the enotices ( email, syslog, files, etc ). I really don't see the point of adding a bunch of stuff to revdep-rebuild. If I am having gcc issues, I run gcc- config, python issues, python-updater. Most users are just going to run revdep- rebuild with the normal parameters and their python will still lay broken.
I think python-updater should be called after a *python upgrade*. If there is a tool to fix stuff which may break on upgrades, why do you tell the user to 'run foo' on a enotice instead of simply running it? If there is a concern it 'might break other stuff' or something like it, you can add a 'check' USE flag. when it is present, the python emerge runs python-updater, otherwise it just sends the enotice.
(In reply to comment #8) > I think python-updater should be called after a *python upgrade*. If there is a > tool to fix stuff which may break on upgrades, why do you tell the user to 'run > foo' on a enotice instead of simply running it? If there is a concern it 'might > break other stuff' or something like it, you can add a 'check' USE flag. when it > is present, the python emerge runs python-updater, otherwise it just sends the > enotice. > At least one problem that comes to mind is that python-updater calls emerge and atm calling emerge inside emerge is not allowed and probably will not be any time soon.
funny that, because that is what i thought when i wrote python-updater. i just noticed that during my recent upgrade with perl, perl-cleaner is run inside of an emerge! is that "legal" so to speak?
(In reply to comment #10) > funny that, because that is what i thought when i wrote python-updater. i just > noticed that during my recent upgrade with perl, perl-cleaner is run inside of > an emerge! is that "legal" so to speak? > Last time I checked no, there are still race-conditions in the code where this could cause problems.
As portage started to encourage users to emerge --depclean after updates, I did basically did revdep-rebuild && emerge --depclean, the latter failed because after just upgrading from 2.6 to 2.7 emerge crashed when it removed python 2.6. The result: a broken system and an angry user looking at a bug report which should have been closed as FIXED about 6 years ago. =[ PS: Any idea on how to recover from this?
(In reply to comment #12) It's completely unrelated to this bug.
python-updater should be maintained as a separate package.
(In reply to comment #12) Bug 357009 is related. You should be able to recover by setting the default interpreter with eselect python. Please use forums.gentoo.org if you need more help.
(In reply to comment #13) > It's completely unrelated to this bug. I don't think this is unrelated. The bug reports states: "I propose calling python-updater from revdep-rebuild." If this would have been done, and revdep-rebuild would have called python-updater, I would not have stumbled upon this issue. I propose to reopen this bug, and I propose that revdep-rebuild should at minimum output a warning that it does not fix reverse dependancies for Python (and possibly some other stuff?) and that users MUST run python-updater, or else things might break (e.g. even portage). Users probably expect revdep-rebuild to fix ALL reverse dependancies, including these Python things. Even the name of the script, "revdep-rebuild", seems to imply this. So in case adding a warning to revdep-rebuild is out of the question, I suggest to change the name of revdep-rebuild to something, which would more precisely reflect what it ACTUALLY does. (In reply to comment #15) > Bug 357009 is related. You should be able to recover by setting the default > interpreter with eselect python. Please use forums.gentoo.org if you need more > help. Thanks. "eselect python" appears to have fixed this.
revdep-rebuild could have an option to run python-updater, haskell-updater, perl-cleaner etc.
Let's look at this with the python rewrite.
