New portages 2.1.4_rc7 and rc4 (which I tested)don't interpret ${ESVN_CO_DIR}right. trunk directory at the end is lost. portage-2.1.3.19 works right. Ebuild has this two lines: ESVN_REPO_URI="svn://svn.berlios.de/codeblocks/trunk" ESVN_CO_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}"/svn-src/${P/-svn}/"${ESVN_REPO_URI##*/}" echoing the ${ESVN_CO_DIR}within ebuild outputs this: /usr/portage/distfiles/svn-src/codeblocks-9999/ instead of /usr/portage/distfiles/svn-src/codeblocks-9999/trunk So I need to add trunk at the end of ${ESVN_CO_DIR} like ${ESVN_CO_DIR}/trunk. But this time stable portage-2.1.3.19 fails, because it interprets one more trunk at the end like this: /trunk/trunk Reproducible: Always Steps to Reproduce: 1.emerge codeblocks-svn-r18 2.if you have portage-2.1.3.19 3.emerge fails Actual Results: ESVN_CO_DIR : /usr/portage/distfiles/svn-src/codeblocks-9999/ Expected Results: ESVN_CO_DIR : /usr/portage/distfiles/svn-src/codeblocks-9999/trunk My arch is ~amd64. dev-util/codeblocks-9999-r18 is from this thread: http://forums.gentoo.org/viewtopic-t-588089-highlight-.html
(In reply to comment #0) > New portages 2.1.4_rc7 and rc4 (which I tested)don't interpret > ${ESVN_CO_DIR}right. trunk directory at the end is lost. portage-2.1.3.19 works > right. Even if it "works right" with 2.1.3.19 it doesn't mean that the ebuild is written correctly. From the 2 lines of the ebuild you posted, I don't see any problem. I couldn't find the ebuild so please attach the whole ebuild to this bug.
Created attachment 137851 [details] codeblocks-9999-r18.ebuild codeblocks-9999-r18.ebuild is attached. Hi, Zac. This is the ebuild that works fine for stable portage-2.1.3.19, but fails for portage-2.1.4_rc7. Thanks.
(In reply to comment #2) > Created an attachment (id=137851) [edit] > codeblocks-9999-r18.ebuild Note that the order of the variable assignments in the ebuild is exactly the opposite of what you posted in comment #0. Apparently this ebuild assumes that it's global scope code will be executed more than once, which is an assumption that will not be supported in >=portage-2.1.4. The main difference between portage-2.1.4 and earlier versions is that global scope code in the ebuild/eclasses is only executed one time instead of once per phase. Any ebuilds/eclasses that assume that they will be sourced more than once need to be fixed to stop making that assumption.
(In reply to comment #3) > Note that the order of the variable assignments in the ebuild is exactly the > opposite of what you posted in comment #0. Apparently this ebuild assumes that > it's global scope code will be executed more than once, which is an assumption > that will not be supported in >=portage-2.1.4. > > The main difference between portage-2.1.4 and earlier versions is that global > scope code in the ebuild/eclasses is only executed one time instead of once per > phase. Any ebuilds/eclasses that assume that they will be sourced more than > once need to be fixed to stop making that assumption. > Thanks. I changed the order of the variable assignments. Now everything works fine.
