Bug 44712 - dev-lang/gpc ebuilds assign to read-only variables.
|
Bug#:
44712
|
Product: Gentoo Linux
|
Version: 1.4
|
Platform: All
|
|
OS/Version: All
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: DUPLICATE
|
Assigned To: george@gentoo.org
|
Reported By: mr_bones_@gentoo.org
|
|
Component: Unspecified
|
|
|
URL:
|
|
Summary: dev-lang/gpc ebuilds assign to read-only variables.
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2004-03-14 16:46 0000
|
Here's a list of ebuilds that assign to portage's read-only variables.
first set of CC's -- teams can you fix up your respective ebuilds and then
remove yourselves from cc list
Fixed - app-emacs/elib and app-emacs/proofgeneral.
adding myself to CC due to QA
adding mobile for pcmcia-cs
added lu_Zero for bochs and lolo for dinero
matsuu, please don't use dosed in src_compile for nbench
added zul for net-irc stuff
wow the three avr- things were DISGUSTING. Absolute rubbish. Whoever did
those, needs to go back and learn how to create ebuilds. Whoever checked them
in could use a lesson in ebuilding as well. /me goes to take a shower now.
avr-binutils, avr-gcc and avr-libc are fixed, HOWEVER, I am NOT convinced ONE
BIT that they are even necessary to have in portage at all.
Ok, sometimes this is the easiest on the only "reasonable" way to go, given
certain precautions are taken, as some packages have interesting ideas on how
to use variables before they define them (for example :)).
dev-lang/gpc:
its a construct of the form:
SAVEP="${P}"
unset P
econf ...
...
P="${SAVEP}"
All thew wrapping is done inside single function, so P is preserved as far as
portage is concerned.
Same story for sys-cluster/mpich...
And these seem to be the only two that I could relate to myself.
Removing myself from CC as seemant requested, but if I missed something please
readd..
George
media-{sound,libs} packages cleaned up
pcmcia-cs-{tools,drivers} fixed.
george, I think MY_P is a better way to go, than to redefine P
all ebuild docs explicitly state that P and other such portage variables are not to be redefined. can you fix please?
Removing the hardened herd.. hardened-gcc is maintained by pappy@gentoo
( adding to CC: )
Add hardened back if I missed something on that list and it belongs to us.
for the baselayout one, we'll need Nick's input, because the assignment was
done to make baselayout packageable as a tbz2
Adding pvdabeel so that he can fix dev-libs/dv* and also add metadata.xml files
adding emacs herd back, for dev-util/cscope
avenj and zul for some of the net-irc stuff
dev-util/cscope is fixed.
fixed jmeter and realplayer
I think realplayer should just be removed from the tree as things stand
sed -i \
-e 's/\$(P)//' `find . -type f | xargs grep -l '\$(P)'` \
|| die "sed failed"
should fix mpich
Regarding comment 37, please use something more safe, such as
grep -frlZ '$(P)' | xargs -0 sed -i -e 's/\$(P)//'
This avoids issues such as spaces/quotes in filenames and argv limitations.
Rather grep -FrlZ '$(P)' . | xargs -0 sed -i -e 's/\$(P)//'
dev-libs/dv* taken care of
fixed baselayout, please don't kill me Az
Fixed mpich. thanks to spyderous for the moral support and agriffis for the
grep | sed fix.
narrowing the cc list now that most are fixed.
Here are the remaining ebuilds:
dev-java/blackdown-jre/blackdown-jre-1.4.2_rc1.ebuild: Readonly variable assignment to A on line 24
dev-java/blackdown-jre/blackdown-jre-1.4.2_rc1.ebuild: Readonly variable assignment to A on line 27
dev-java/blackdown-jre/blackdown-jre-1.4.2_rc1.ebuild: Readonly variable assignment to A on line 30
dev-java/blackdown-jre/blackdown-jre-1.4.2_rc1.ebuild: Readonly variable assignment to A on line 33
dev-lang/gpc/gpc-2.1.ebuild: Readonly variable assignment to P on line 26
dev-lang/gpc/gpc-20030209.ebuild: Readonly variable assignment to P on line 99
>george, I think MY_P is a better way to go, than to redefine P
Seemant: its not that I need to use the modified $P somewhere, its that the *existance* of P at that very point breaks package build scripts (they use it internally).
If you've read my comment, you see that I am just cleanly wrapping $P around few configure/make calls (saving and unsetting P before and restoring P later), all *within the same function*, so that portage *does not even see that I do it*. And yea, I did it this way on purpose, exactly to avoid breakage we are worried about in this bug (otherwise I would have to do heavy patching on Makefiles, etc.)...
Mr. Bones:
see my comment #15. I took care of that when I was modifying these ebuilds in the first place (so it never was an issue). That's the same situation for both dev-lang/gpc and sys-cluster/mpich.
George
I read your comment from before, but I disagree that wrapping the build process
in the unset P code is the way to go. I fixed sys-cluster/mpich and I
belive gpc should be patched as well to not use P or to use it correctly
in the build process.
Well, I agree that, given the way portage deals with env vars this would be the
better way to go. (although I keep my position, that it would be better if
portage would have done pre-expansion of its own env vars before passing
ebuilds to bash. That seems a more "correct" way to go, than polluting local
environmant. (Vars defined in the ebuild are Ok either way) But this is the way
it is now, so we have to deal with it.)
Although in the case of gpc the "fix" will not be right away since
1. strictly speaking the ebuild is not broken
2. it is a low priority one and I have a more urgent issues on my hands right
now (and the fix does not seem to be trivial).
But its on my TODO list, so I'll get to it eventually..
George
dev-java/blackdown-jre has been fixed by zx.
dev-lang/gpc is the only package in portage that does this now so I'm changing
the summary and and passing it off to george to get it off the wrangler list.
Marking this as a dup. Will be tracking this package via #48377
*** This bug has been marked as a duplicate of 48377 ***
