Portage started to die if an ebuild passed an atom into has_version and similar function calls that are not valid in the ebuild's EAPI. One source of those calls is the python eclass, which usees slot atoms under some circumstances, which are only allowed in >=EAPI-1. Ebuilds need either be changed to use EAPI-0 atoms only or have to be migrated to an appropriate EAPI. A build log from a failed merge is attached to bug 340387.
why dont you fix python.eclass instead
(In reply to comment #1) > why dont you fix python.eclass instead > From bug 340407: > python.eclass will drop support for EAPI="0" when all ebuilds are updated to > newer EAPIs. >
yeah, i dont think so. i count at least 650 ebuilds in the tree that inherit python in some way are using EAPI=0. python.eclass dropping EAPI=0 needs to be discussed on gentoo-dev before you go spamming maintainers with possibly invalid bugs. in other words, dont file any more bugs for this until it gets resolved.
(In reply to comment #3) in other words, dont file any > more bugs for this until it gets resolved. > Only a minority of EAPI-0 ebuilds inheriting the python.eclass is affected by this problem and all of them have their bug filed.
Something unusual i discovered is that sys-apps/file is one of these builds that needs fixed. Howerver i fails with portage-2.2_rc92 but not with portage-2.2_rc91. Does that mean it is part of a seperate issue? Although it does fail with the invaild atom dev-lang/python:2.6 warning/error. This has me puzzled. Anyone care to explain? Or have any ideas?
(In reply to comment #5) > Howerver i fails with portage-2.2_rc92 but not with portage-2.2_rc91. > This check has been introduced between rc91 and rc92.
(In reply to comment #4) > Only a minority of EAPI-0 ebuilds inheriting the python.eclass is affected by > this problem and all of them have their bug filed. which is completely irrelevant. the statement was "python.eclass will not support EAPI 0" which means anyone who inherits python eclass is affected.
For bug 340399, I closed as RESO:LATER following suit of other bugs on this tracker. It doesn't make much sense to fix the symptoms instead of the root cause to me. I'd say fix the eclass.
In portage-2.2_rc93 the invalid atom results in an eqawarn message instead of a die. The new eqawarn message is also included in portage-2.1.9.15: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5de77e44aa10ed5ff8262c184df651c2adc868bd
supposedly the python eclass has been fixed which means ebuilds need not be changed anymore
(In reply to comment #10) > supposedly the python eclass has been fixed which means ebuilds need not be > changed anymore > Not all bugs here are caused by the python eclass. There remain two bugs to be fixed: bug 340469 and bug 340465.
