Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 201383 - sys-apps/portage-2.1.4_rc7 interprets ${ESVN_CO_DIR}" without the trunk dir at the end
Summary: sys-apps/portage-2.1.4_rc7 interprets ${ESVN_CO_DIR}" without the trunk dir a...
Status: VERIFIED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-05 16:53 UTC by keenblade
Modified: 2007-12-06 03:03 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
codeblocks-9999-r18.ebuild (codeblocks-9999-r18.ebuild,4.00 KB, text/plain)
2007-12-05 22:36 UTC, keenblade
Details

Note You need to log in before you can comment on or make changes to this bug.
Description keenblade 2007-12-05 16:53:00 UTC
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
Comment 1 Zac Medico gentoo-dev 2007-12-05 17:49:49 UTC
(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. 
Comment 2 keenblade 2007-12-05 22:36:03 UTC
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.
Comment 3 Zac Medico gentoo-dev 2007-12-05 23:41:59 UTC
(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.
Comment 4 keenblade 2007-12-06 03:03:13 UTC
(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.