While using portage-2.0.24 (and earlier) I noticed that PORTDIR_OVERLAY doesn't yet work with eclasses. I would like that functionality added for developing custom eclasses.
This should be fixed in Portage 2.0.35 (I upgraded inherit() to look in $PORTDIR_OVERLAY if it is set.)
There is a "skip" missing in the inherit()-function, right above the "continue" in the block which treats the PORTDIR_OVERLAY-eclasses! Without this "skip" the same eclass is included in an endless loop.
Of course I ment "shift", not "skip". Excuse me!
Yep, confirmed here! In ebuild.sh, inherit(): debug-print "inherit: $1 -> $location" source "$location" || die "died sourcing $location in inherit()" #continue processing, skip sourcing of one in $ECLASSDIR shift <----- this word is the key ;o) continue Thanks Peter!
*** Bug 8413 has been marked as a duplicate of this bug. ***
Why is this bug not fixed already? It's so simple and needs only one line added to ebuild.sh! Thanks, Peter
*** Bug 7909 has been marked as a duplicate of this bug. ***
Will be in 2.0.40
It stopped working correctly. I believe the caching code does not properly use the overlay dir. Basically what happens. I delete the cache. I do an emerge -p galeon (which uses my own eclass). The ebuild dies as a "cache entry" cannot be found. I copy the eclass to /usr/portage/eclass and do a pretend. Now it works. Now I delete the eclass from /usr/portage/eclass, and it STILL works.
I just had a similar problems as did Paul. I was using Paul's most excellent set of ebuilds for gcc-2.95.3-r8 to build mozilla and galeon in gentoo1.4_rc1 (see bug 9016). Anyways, after setting # export ECLASS_DEBUG_OUTPUT="on" and doing # emerge gcc-2.95.3-r8.ebuild I noticed in /var/tmp/portage/gcc-2.95.3-r8/temp/eclass-debug.log: inherit: gcc-compat -> /usr/portage/eclass/gcc-compat.eclass even though there was no /usr/portage/eclass/gcc-compat.eclass! Further, it was not seeing the /usr/local/portage/eclass/gcc-compat.elcass that actually did exist. Adding some debug statements to /usr/lib/portage/bin/ebuild.sh I found that emerge thought PORTDIR_OVERLAY was null even though I have this set in /etc/make.conf as follows: PORTDIR_OVERLAY=/usr/local/portage After explicitly setting and exporting it at the command line, the emerge saw the correct eclass: inherit: gcc-compat -> /usr/local/portage/eclass/gcc-compat.eclass and everything seems to work again. So I think there may be two problems: 1. A cache problem that still sees an eclass where there is no longer one. 2. A problem of PORTDIR_OVERLAY not getting into the environment.
*** Bug 14130 has been marked as a duplicate of this bug. ***
This doesn't seem to be fixed in portage-2.0.47-r10: spark ion-devel # ls /var/db/pkg/sys-apps/ | grep portage portage-2.0.47-r10 spark ion-devel # grep PORTDIR_OVERLAY /etc/make.conf # PORTDIR_OVERLAY is a directory where local ebuilds may be stored without PORTDIR_OVERLAY=/usr/local/portage spark ion-devel # ls -l /usr/local/portage/eclass/ion.eclass -rw-r--r-- 1 root root 1884 Mar 28 10:47 /usr/local/portage/eclass/ion.eclass spark ion-devel # ebuild --debug ion-devel-20030327-r1.ebuild install /usr/sbin/ebuild.sh: line 904: /usr/portage/eclass/ion.eclass: No such file or directory !!! ERROR: x11-wm/ion-devel-20030327-r1 failed. !!! Function inherit, Line 904, Exitcode 1 !!! died sourcing /usr/portage/eclass/ion.eclass in inherit() aux_get(): (0) Error in x11-wm/ion-devel-20030327-r1 ebuild. Check for syntax error or corruption in the ebuild. (--debug) doebuild(): aux_get() error; aborting. Symlinking individual eclass from /usr/local/portage/eclass to /usr/portage/eclass seems to temporarily fix it, but this will get overwrittem each time I emerge sync. Regards, Tom
It works, it's just that you need to manually export it: export PORTDIR_OVERLAY="/usr/local/portage" ebuild --debug ion-devel-20030327-r1.ebuild install There is probably a one line fix for this... source /etc/make.conf might be it, but shouldn't it have already been sourced before ebuild.sh starts? Or perhaps there is a problem inheriting PORTDIR_OVERLAY
Ok, I spent some part of this evening dwelving into the magic world of portage and ebuilds. It was a most enjoyable experience as I don't speak python at all. ;) However, after patching /usr/lib/python2.2/site-packages/portage.py, I got this to work, and as previously mentioned, it's a one-line fix. The patch is simple, just add "PORTDIR_OVERLAY" to the 'incrementals' array on line 50. The corresponding file in the portage source is pym/portage.py. I'd post a proper patch, but it's probably easier to just change the file directly. ;)
same issue with profile dir !
though the profile directory is hardcoded to PORTDIR in portage.py: mystique:fredde:/usr/lib/python2.2/site-packages>grep profiles portage.py updpath=os.path.normpath(settings["PORTDIR"]+"/profiles/updates") thirdpartymirrors=grabdict(settings["PORTDIR"]+"/profiles/thirdpartymirrors") if os.path.exists(settings["PORTDIR"]+"/profiles/categories"): categories=grabfile(settings["PORTDIR"]+"/profiles/categories") pkgmasklines=grabfile(settings["PORTDIR"]+"/profiles/package.mask") Is the profile directory supposed to be able to begin with?
I can also confirm that the oneliner about adding PORTDIR_OVERLAY to incrementals fixes this. Is there no chance to get this applied to an upcoming portage release? I'd even vote for upping the severity on this one since it is functionally broken.
Created attachment 12264 [details, diff] patch to fix eclass support under PORTDIR_OVERLAY Since no one has posted a patch yet, I figure it is time. Especially considering that this bug has existed since 2002 and the new portage (2.0.48) doesn't fix it; and the fact that this is a *very* simple one-line fix. I noticed that the "no/bad digest" problem for ebuilds under PORDIR_OVERLAY has been fixed, so with this proposed fix, portage will fully support local trees (eclasses and all). Please apply this, or at least let us know what the hold-up is. Thank you for your time.
I verify that the patch still applies exactly to the latest portage 2.0.48-r1, and works 100%. Carpaski: could you please attempt to have this in the next release. It is invaluable in testing the more complex eclasses such as PHP.
Added PORTDIR_OVERLAY to incrementals for next release, but I do not understand this fix in relation to the code it was submitted against. Incrementals allows appending between configuration layers and PORTDIR_OVERLAY was not allowed to be multiple entries when this bug was created. I added it as it makes sense for the current code, but I'm not sure what was supposed to happen with that particular change.
i think this is working with 2.0.49
it is working.
