| Summary: | dev-python/python-exec-10000.2 was masked, but the system still needs it | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nikos Chantziaras <realnc> |
| Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alexandre.guimaraes, me, qa, whissi |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Nikos Chantziaras
2014-03-07 14:22:45 UTC
But if something needs it... you had to have it installed. So you uninstalled it prematurely, didn't you? dev-python/dnspython-1.11.1 app-text/calibre-1.25 requires dev-python/python-exec-10000.2 (In reply to Michał Górny from comment #1) > But if something needs it... you had to have it installed. So you > uninstalled it prematurely, didn't you? Yes. emerge informed me that "one of your installed packages is masked". That obviously means that it hints me at uninstalling it, otherwise why even mention it? I don't think gnome-base/gconf really depends on dev-python/python-exec. I had the same issue with different packages and simply remerging those package solve the issue. Maybe try `emerge gnome-base/gconf` and see what happend. The process of remerging is however painful because there is many packages that "required" dev-python/python-exec The trick here is that current VDB entries point at dev-python/python-exec, but a reinstall will no longer use it. Thus all packages with these VDB entries need to be manually re-emerged, for example: emerge -1 `grep -R dev-python/python-exec /var/db/pkg/*/*/DEPEND | cut -d "/" -f 5,6 | sed -e 's/^/=/'` Of course that's not an intuitive solution that any users will figure out by themselves, so this will be great fun to clean up. Ok, removed the mask for now. We'll reintroduce it with news item explaining how to rebuild the remaining deps. (In reply to Patrick Lauer from comment #5) > Thus all packages with these VDB entries need to be manually re-emerged, for > example: > > emerge -1 `grep -R dev-python/python-exec /var/db/pkg/*/*/DEPEND | cut -d > "/" -f 5,6 | sed -e 's/^/=/'` A solution without emerging anything would be great. Like editing the VDB entries directly. There is actually no reason at all to re-emerge. (In reply to Michał Górny from comment #6) > Ok, removed the mask for now. We'll reintroduce it with news item explaining > how to rebuild the remaining deps. Would a revision bump on those remaining reverse dependencies be viable? (If there are only a few, unsure how many reverse dependencies we talk about) (In reply to Tom Wijsman (TomWij) from comment #8) > (In reply to Michał Górny from comment #6) > > Ok, removed the mask for now. We'll reintroduce it with news item explaining > > how to rebuild the remaining deps. > > Would a revision bump on those remaining reverse dependencies be viable? > > (If there are only a few, unsure how many reverse dependencies we talk about) All python-r1 packages that haven't been bumped since dev-lang/python-exec was introduced :). (In reply to Nikos Chantziaras from comment #7) > (In reply to Patrick Lauer from comment #5) > > Thus all packages with these VDB entries need to be manually re-emerged, for > > example: > > > > emerge -1 `grep -R dev-python/python-exec /var/db/pkg/*/*/DEPEND | cut -d > > "/" -f 5,6 | sed -e 's/^/=/'` > > A solution without emerging anything would be great. Like editing the VDB > entries directly. There is actually no reason at all to re-emerge. Yeah, something like `grep -Rh dev-python/python-exec /var/db/pkg/*/*/{,R,P}DEPEND | sed 's/[!<>=~]*dev-python\/python-exec[0-9_:\[(),/=*+-]*[a-z0-9_:\[(),/=*+-]*\]*//g' | sed 's/ / /'` could be done; though, given its impact it is better verified for correctness a few times, so, don't go and blindly turn this into a sed -i version without confirming it does its job. It could leave || ( ... ) and ( ... ) blocks with one package less; no idea how Portage would be affected, I guess it is fine with such blocks containing a single package? Whether or not to re-emerge again kind of depends on the amount of packages; if just a few, it's safer and easier to go the re-emerge road, if it are quite a lot, it more interesting and helpful to spare out all the re-emerging with a verified sed command that takes at most some seconds. (In reply to Michał Górny from comment #6) > Ok, removed the mask for now. We'll reintroduce it with news item explaining > how to rebuild the remaining deps. Thinking about this again, I wonder if a news item is appropriate if it is just for the sake of removing an empty package. It could be more interesting to look in having some sort of mechanism that allows us to nuke a package like this through profiles/updates or so towards the future. Or well, changing and/or respecting the dynamic dependencies behavior is another option. Granted, that would take a while; so, we have to rely on a news item right now. solved ? asked since i have thhis problem today :( will emerge -e @system solve it ? problem i think it is that there is multislot, but only a fev updated to latest slot of python-exec diffrence slots and diffrence categories No new input, hopefully solved for good. |
