Apparently someone move dev-python/PyXML to dev-python/PyXML-py21. This causes errors if you had PyXML installed before this move. % qpkg -I -nc | grep PyXML dev-python/PyXML % emerge PyXML -pv These are the packages that I would merge, in order: Calculating dependencies emerge: there are no masked or unmasked ebuilds to satisfy "PyXML". !!! Error calculating dependencies. Please correct. This is HORRIBLE....Now I've got PyXML installed but no way to uninstall it and I can't 'emerge world' due to this error. In my opinion this is a MAJOR mistake for Gentoo to allow this type of moving ebuilds. ARggggghhhhhhhhhh! This is not the first time this had been done either... Reproducible: Always Steps to Reproduce: 1. 2. 3. If you are going to 'fork' from an ebuild, leave the original ebuild there. There was no reason to delete dev-python/PyXML.
Um... Didn't you just say it was moved... Did you try 'emerge -PyXML-py21' ? And if emerge world is the actual problem, check and fix your world file, and report back.
O.K. I'll try again. How do I know what version of PyXML I had installed? The original PyXML directory and ebuild were deleted. Are you suggesting I just emerge PyXML-py21 and * hope * everything is O.K.? This is a terrible way to do things... This says I have PyXML installed... % qpkg -I -nc | grep PyXML dev-python/PyXML
This bug needs to be re-opened. There are further issues than just this. Apparently there are builds which depend on dev-python/PyXML still but there is no dev-python/PyXML to install. I cant emerge -uD world. Calculating world dependencies \ emerge: there are no masked or unmasked ebuilds to satisfy "dev-python/PyXML". !!! Problem with ebuild x11-themes/gnome-themes-2.2.2-r1 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. A temporary fix this this problem is to add a PyXML virtual to your virtuals file, but this gets overwritten on every sync. Add a line similar to this: dev-python/PyXML dev-python/PyXML-py21 It is my opinion that this should be added officially in cvs untill ebuilds use the new dep. There are already other such virtuals in the file: x11-libs/xaw x11-libs/Xaw3d sys-apps/console-tools sys-apps/kbd sys-apps/reiserfs-utils sys-apps/reiserfsprogs #sys-apps/modutils sys-apps/module-init-tools #virtual/modutils sys-apps/module-init-tools (yeah, I know the last two are commented out, but when we transition to the 2.6 kernel they'll be uncommented and wham... everything will instantly work) Note: the fields are tab delimited. Also, if you dont know what virtual file you are using, you can edit /etc/make.profile/virtuals, as /etc/make.profile is just a symbolic link to your actual profile in the portage tree. After applying this /temporary/ fix that only lasts untill your next sync, all seems to be well: lordviram root # nice -n 10 emerge --usepkg -uD world -p These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] dev-lang/python-2.1.3-r1 [2.2.3-r1] [ebuild N ] dev-python/PyXML-py21-0.8.1 [ebuild U ] net-misc/rsync-2.5.6-r3 [2.5.6-r2] [ebuild U ] dev-libs/DirectFB-0.9.18 [0.9.17] As for uninstalling the old PyXML package, you can do this: emerge unmerge /var/db/pkg/dev-python/pyxml-0.8.2/PyXML-0.8.2.ebuild that should work /perfectly/ and is not in any way dependant on the contents of the portage tree. The above worked for me... if it does not work for you, then just emerge sync && emerge portage. I am unsure which version first introduced the ability to use ebuilds direct from the package database, but the currently unmasked portage version on x86 does. I hope this solves your problem... it seems to solve mine.
No, there shouldn't be anymore references to dev-python/PyXML in the tree. I think you need to resync and then you should be fine.
I would like to add that just sync'ing portage does not resolve this problem is all instances. Somehow, I had a machine that had transitioned to the new ebuild catagories for PyXML except that one ebuild (libglade) still thought it depended on PyXML. What a headache, couldn't unmerge it, couldn't remerge it - nothing. That is until I saw Travis' post above about adding that little line to the virtuals file. I then updated anything that still depended on PyXML. Thanks Travis
this probably should be closed. was actually due to some screwup with renaming PyXML to pyxml sometime 2 months ago.
