Summary: | dev-lang/gpc ebuilds assign to read-only variables. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mr. Bones. (RETIRED) <mr_bones_> |
Component: | [OLD] Unspecified | Assignee: | George Shapovalov (RETIRED) <george> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | spider |
Priority: | High | ||
Version: | 1.4 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 44503, 44504, 44505, 44506, 44507 | ||
Bug Blocks: | |||
Attachments: |
list of ebuilds that assign to portage's read-only variables
updated list updated list again with the updated list. |
Description
Mr. Bones. (RETIRED)
2004-03-14 16:46:52 UTC
Created attachment 27383 [details]
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. gnome-base/gconf fixed adding myself to CC due to QA udftools fixed 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 gtk-systrace fixed added zul for net-irc stuff bochs is fixed ratpoison fixed 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. Created attachment 27387 [details]
updated list
nbench fixed. just fixed ical 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 Fixed ninja. I fixed net-print/poster added jhhudso@gentoo.org for net-misc/aria oer-mysql is fixed. fixed dev-util/xmingw* dev-util/cscope is fixed. Created attachment 27436 [details]
updated list
rphillips@gentoo.org for bashburn 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 fixed dev-db/dbbalancer 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-java/* taken care of Created attachment 27508 [details]
again with the updated list.
qiv fixed aria fix0red bashburn fixed subversion fixed 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. fixed hardened-gcc narrowing the cc list now that most are fixed. added george for gpc 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 *** |