as requested by http://bugs.gentoo.org/show_bug.cgi?id=265747#c22 banshee-x86-32 / # python -c 'import portage ; print [(x, \ portage.portdb._repo_info[x].eclass_db.porttrees) for x in \ portage.portdb._repo_info]' [(u'/usr/portage', (u'/usr/portage', u'/NOC4/portage')), (u'/NOC4/portage', (u'/usr/portage', u'/NOC4/portage', u'/NOC4/portage'))]
It seems like it's adding /NOC4/portage to the eclass path, like you wanted. Are the desired eclasses really located in the /NOC4/portage/eclass/ directory?
(In reply to comment #1) Yes, heres an example, 2 build hosts with the same portage tree mounted in each, one using 2.2_rc48 the other 2.1.6.7 we deliberatly create a syntax error in the overlay eclass to see if it is ever processed, then emerge -av dev-php5/suhosin for example on 2.2_rc48: nothing is overidden it pulls in the inherit's from the main portage tree, so no errors. emerge -av dev-php5/suhosin * IMPORTANT: 4 news items need reading for repository 'gentoo'. * Use eselect news to read news items. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-php5/suhosin-0.9.29 0 kB on 2.1.6.7: inherit overides pulled in from noc4, the syntax error shows up as expected banshee-x86-64 / # emerge -av dev-php5/suhosin * Overlay eclasses override eclasses from PORTDIR: * * '/NOC4/portage/eclass/apache-module.eclass' * '/NOC4/portage/eclass/depend.apache.eclass' * '/NOC4/portage/eclass/depend.php.eclass' * '/NOC4/portage/eclass/php-ext-base-r1.eclass' * '/NOC4/portage/eclass/php-ext-source-r1.eclass' * '/NOC4/portage/eclass/php-pear-lib-r1.eclass' * '/NOC4/portage/eclass/php-pear-r1.eclass' * '/NOC4/portage/eclass/phpconfutils.eclass' * '/NOC4/portage/eclass/webapp-apache.eclass' * * It is best to avoid overriding eclasses from PORTDIR because it will * trigger invalidation of cached ebuild metadata that is distributed with * the portage tree. If you must override eclasses from PORTDIR then you * are advised to add FEATURES="metadata-transfer" to /etc/make.conf and to * run `emerge --regen` after each time that you run `emerge --sync`. Set * PORTAGE_ECLASS_WARNING_ENABLE="0" in /etc/make.conf if you would like to * disable this warning. * IMPORTANT: 2 news items need reading for repository 'gentoo'. * Use eselect news to read news items. These are the packages that would be merged, in order: Calculating dependencies //NOC4/portage/eclass/php-ext-source-r1.eclass: line 17: sdlfkjsdlkjf: command not found ... done! /NOC4/portage/eclass/php-ext-source-r1.eclass: line 17: sdlfkjsdlkjf: command not found /NOC4/portage/eclass/php-ext-source-r1.eclass: line 17: sdlfkjsdlkjf: command not found /NOC4/portage/eclass/php-ext-source-r1.eclass: line 17: sdlfkjsdlkjf: command not found /NOC4/portage/eclass/php-ext-source-r1.eclass: line 17: sdlfkjsdlkjf: command not found [ebuild R ] dev-php5/suhosin-0.9.29 0 kB
Created attachment 209481 [details, diff] add --debug support for inherit If this patch is saved as /tmp/inherit_debug.patch, then it can be applied as follows: patch /usr/lib/portage/bin/ebuild.sh /tmp/inherit_debug.patch Please apply this patch and then run this command on an ebuild that's supposed to inherit an overridden eclass, and post the output: ebuild <path to ebuild> depend --debug
Created attachment 209493 [details] depend debug log output of dependency patched patched ebuild.sh
(In reply to comment #4) > Created an attachment (id=209493) [details] > depend debug log > > output of dependency patched patched ebuild.sh The output shows that it is correctly inheriting eclasses from your overlay. Which version of portage was that produced with? Was it with 2.2_rc48? Please make sure to do it with the version which causes problems for you. If that was 2.2_rc48, then we also need to check emerge --debug output for building an ebuild, since we were not able to reproduce the problem with ebuild(1).
Created attachment 209526 [details] emerge debug log with output from 2.1.6.7 & 2.2_rc48 resp. (In reply to comment #5) Sorry yes that is from 2.2_rc48 :) emerge debug log attached with output from 2.1.6.7 & 2.2_rc48 resp. we can see here that portage did not pull in the correct eclass and consequently it also pulled in the incorrect dependency (since in this case the eclass and it's own inherit's set up DEPEND/RDEPEND) of dev-lang/php5 which we have masked Portage 2.1.6.7: Parent: ('ebuild', '/', 'dev-php5/suhosin-0.9.29', 'merge') Depstring: =dev-lang/php-noc4-5* =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool >=sys-devel/m4-1.4.3 >=sys-devel/libtool-1.5.18 Priority: hard Candidates: ['>=sys-devel/libtool-1.5.18', 'sys-devel/libtool', '>=sys-devel/autoconf-2.61', '=sys-devel/automake-1.10*', '=dev-lang/php-noc4-5*', '>=sys-devel/m4-1.4.3'] Portage 2.2_rc48 : Parent: ('ebuild', '/', 'dev-php5/suhosin-0.9.29', 'merge') Depstring: =dev-lang/php-5* =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool >=sys-devel/m4-1.4.3 >=sys-devel/libtool-1.5.18 Priority: buildtime Candidates: ['>=sys-devel/libtool-1.5.18', 'sys-devel/libtool', '>=sys-devel/autoconf-2.61', '=sys-devel/automake-1.10*', '>=sys-devel/m4-1.4.3', '=dev-lang/php-5*']
> (In reply to comment #5) > we can see here that portage did not pull in the correct eclass and > consequently it also > pulled in the incorrect dependency (since in this case the eclass and it's own > inherit's set up DEPEND/RDEPEND) of dev-lang/php5 which we have masked It's possible that this problem is related to the dependency cache. Does it help if you remove $PORTDIR/metadata/cache as in bug #276264 (the portage.5 man page has since been updated to suggest this)?
(In reply to comment #7) > It's possible that this problem is related to the dependency cache. Does it > help if you remove $PORTDIR/metadata/cache as in bug #276264 (the portage.5 man > page has since been updated to suggest this)? > Normally when syncing we do emerge --regen after but it seems that removing the cache and then doing emerge --regen fixed the problem, and everything is inherited as before! :)
Ok, then it seems to be the same issues as bug 276264. *** This bug has been marked as a duplicate of bug 276264 ***
