Unfortunately, I can not specify which concrete syncing caused this problem. The problem is: all xxx-cvs.ebuild and xxx-svn.ebuild files fetch/update repositories to/in PORTAGE_TMPDIR instead of DISTDIR. You see, a fetching the whole repo tree discredits repo idea at all. I have not found anything cvs/svn-src dirs specific in 'man make.conf'. portage-2.1_pre3-r1 is in use.
This appears to be an issue specific to portage-2.1_pre3-r1, if I reinstall portage-2.1_pre2 cvs ebuilds (specifically, x11-libs/evas) works correctly. I've worked around the issue by adding these to my make.conf: ECVS_TOP_DIR="/usr/portage/distfiles/cvs-src" ESVN_STORE_DIR="/usr/portage/distfiles/svn-src" Expected behaviour (<=portage-2.1_pre2): * Fetching CVS module e17/libs/evas into /usr/portage/distfiles/cvs-src ... Behaviour with portage-2.1_pre3-r1: * Fetching CVS module e17/libs/evas into /var/tmp/portage/evas-9999/distdir/cvs-src ...
*** Bug 117526 has been marked as a duplicate of this bug. ***
*** Bug 117784 has been marked as a duplicate of this bug. ***
Suggested from ciaran is addition of another var that holds the actual distdir, and modify eclasses in question to use that directory. Would work, although I'd like solar's input on any outstanding perm/security issues with our existing cvs/svn handling- that and any suggestions of improvements we should do since the opportunity exists now.
Perhaps for an ugly interim hack, the eclasses can be modified to use `portageq envvar DISTDIR`. :)
(In reply to comment #4) > Suggested from ciaran is addition of another var that holds the actual distdir, > and modify eclasses in question to use that directory. Would work, although > I'd like solar's input on any outstanding perm/security issues with our > existing cvs/svn handling- that and any suggestions of improvements we should > do since the opportunity exists now. Well even with the change to making cvs/svn/live ebuilds save files to another dir other than $DISTDIR wont solve the real problem of any user in the portage group can gain uid 0 pretty easy. The default /var/tmp/portage itself is a big apart of the risk due to the ../ being 2777 (pick any of the RPATH bugs for a perfect example) and users & devs alike doing stuff like rm -rf /var/tmp/portage Now for the DISTDIR handling in general. I'm kinda opposed to distdir mangling as it invalidates perfectly valid existing scripts that do stuff like post merge distdir cleanups. Another var would solve that but then poof we just added quite a bit of complexity to every existing script. So whats the real gain of DISTDIR= symlinking? Does it need to be enabled for every EBUILD_PHASE or was it's goal to solve a specific problem with a specific phase?
Created attachment 76363 [details, diff] 2.1_pre3-distdir-revert.patch If you urgently need to use the cvs/svn eclasses, this well revert the "magic" distdir behavior. It backs out the relevant hunk from here: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage.py?r1=2469&r2=2474
> Now for the DISTDIR handling in general. I'm kinda opposed to distdir mangling > as it invalidates perfectly valid existing scripts that do stuff like post > merge distdir cleanups. Another var would solve that but then poof we just > added quite a bit of complexity to every existing script. Not worried about breaking your script; design wise, your post distfile cleansing should occur in a different manner. > So whats the real gain of DISTDIR= symlinking? Does it need to be enabled for > every EBUILD_PHASE or was it's goal to solve a specific problem with a > specific phase? Gain is there is no unstated access to DISTDIR by ebuilds. Does a number on restrict="fetch" packages where devs forget to list a file in SRC_URI; does the same for normal packages, also. It also lays the ground work for multiple distdirs, although that's minor. Exempting cvs/svn reasons, not going to revert this change without further args against it- the QA benefit outweigh breaking some custom trickery (sorry :/ )
Brian, Simply saying "it should occur in a different manner" is not enough nor a good way to work with others on the team. This should remain a REGRESSION blocking any releases till such time as an alt variable is provided when needing to access the real DISTDIR=
It *is* a regression, see the keywords. No stable release till it's fixed, meanwhile the 2.1 releases are developmental releases- bugs do occur. Not going to leave it broke, it will be fixed so just relax. Right now the nasty var hack works, but I'd rather avoid that so I'm digging around for other stuff.
Created attachment 76492 [details, diff] fixup.patch Apply this manually for testing please, it adds PORTAGE_ACTUAL_DISTDIR var setting to portage. already modified the eclasses in question to use this var if available, so it should revert the regression.
> Apply this manually for testing please, it adds PORTAGE_ACTUAL_DISTDIR var > setting to portage. I'm not portage developer. What must I test? OK, I can patch 'portage.py' file. And ... what? Must I modify 'make.conf'? xxx-svn/xxx-cvs ebuilds? I'm ready, but I don't know what to do :-)
seems to work here. just have to mke sure those svn/cvs ebuilds/eclasses now use the PORTAGE_ACTUAL_DISTDIR where required
works for me as well. @Andrew: The cvs/svn ebuild you want to merge should contain a line similar to this: ECVS_TOP_DIR="${DISTDIR}/cvs-src/${PN}" If it doesn't then add it yourself, then replace the DISTDIR variable like this: ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR}/cvs-src/${PN}"
ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" ^^^ use that instead. ECVS_TOP_DIR doesn't specify the PN iirc, plus the var substitution I tagged in there is compatible both with older portages and with portages that have the symlinking in use. All in all, only 4 mods in the tree for this- people shouldn't have to duplicate it themselves, but if they need to, raid from subversion.eclass and/or cvs.eclass for example of how to do it. commited, meanwhile.
(In reply to comment #15) > ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" > ^^^ use that instead. I have tried to replace ECVS_TOP_DIR="${DISTDIR}/cvs-src" string with this one: ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" Nevertheless, I have got: >>> checksums files ;-) files/digest-pcb-cvs-0.3 >>> Unpacking source... * Fetching CVS module pcb into /wrk/tmp/portage/portage/pcb-cvs-0.3/distdir/cvs-src/ ... I have DISTDIR="/x/portage/distfiles" PORTAGE_TMPDIR="/wrk/tmp/portage" in my make.conf file. Have I missed something? Must I reopen the issue? Must I supply some additional info?
(In reply to comment #16) > string with this one: > ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" > > Nevertheless, I have got: > * Fetching CVS module pcb into > /wrk/tmp/portage/portage/pcb-cvs-0.3/distdir/cvs-src/ ... Assuming you're not running with the patch ;)
(In reply to comment #17) > Assuming you're not running with the patch ;) You are right. I was not waked up completely :-) With the patch I was able to do a work with one of my '-cvs' ebuild. Thanks!
${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}} would be the correct syntax.
I blame solar winds for my last comment. Sorry about that ..
*** Bug 123644 has been marked as a duplicate of this bug. ***
