instead, portage should utilize an eclass and auto inherit it that way when we want to fix something in the suite of functions (say epatch or edos2unix or flag-o-matic stuff) we dont have to push out a new version of portage, the fix will hit rsync servers in like 30 minutes
I am pro this, as this is the whole reason for eutils.eclass and not bugging Nick back then to add to portage - Some things you just cannot wait on a new portage revision ...
*** Bug 33429 has been marked as a duplicate of this bug. ***
another reason... enewuser in extra_functions is broken, on line 492 it calls fperms ${euser} ${ehome} which is just wrong since fperms is a wrapper for chmod not chown
could we please have this issue resolved now ? i just emerged the latest portage (2.0.50_pre15) only to find that i am no longer able to override the extra_functions.sh by using 'inherit eutils' ... that means a whole bunch of old bugs that were fixed in the eutils.eclass (epatch, enewuser, enewgroup) are going to start cropping up again in my eyes, the fix here is pretty trivial ... perhaps i'm missing something ?
Against extra_functions.sh, a weird thing that is happening: gcc and glibc ebuilds call strip-flags from flag-o-matic.eclass, xfree instead calls strip-flags from extra_functions.sh (flag-o-matic is inherited _after_ strip-flags). The two functions are quite different, and I'm quite sure that they don't have the same effect on flags. If extra_functions.sh is not going away, at least it should be brought up to date for 2.0.50 to avoid these behaviours.
I also agree that an auto-inherited eclass would be a very good thing. I've understood that working on bug #37491: this patch provides a new function (eecho() if you read the report, but that's not important) that some devs could use in ebuilds to display messages to the users when einfo, ewarn, etc. don't fit their tastes. Anyway, what is does is not important, but I wondered how to do the transition, ie how to provide the function to users who don't have yet a portage version that provides it. A standard auto-inherited eclass would definitly be the easiest way to do it. Another practical use would be for displaying some emergency notices. For instance if it happens that a portage release is really badly broken, then this eclass could be used to force the update. Something like this: has_version =sys-apps/portage-the.broken.version \ && [ "${PN}" != "portage" ] \ && eerror "Your portage version is broken, please update." \ && die "Portage update required." That's a problem imho that their is currently no such emergency procedure (masking is not enough once the broken version is installed). I think this eclass should be inherited in a special way, without "eclassname_function" renamings (so that it allows to really overide some broken functions).
See bug 49179 ... I've just finished removing the need for the flag-o-matic functions in extra_functions.sh
Created attachment 30169 [details] missing-eutils.txt Here's the list of functions provided by extra_functions.sh which come from eutils: draw_line epatch enewuser enewgroup edos2unix So the attachment is the output of... find . -name \*.ebuild | xargs grep -L '^inherit.*eutils' | xargs grep -wFf eutils-list.txt | sort | tee missing-eutils.txt
sed 's/:.*//' missing-eutils.txt | xargs perl -0777 -i -pe 'if (!/^inherit.*eutils/m) { s/^inherit.*/$& eutils/m || s/^$/\ninherit eutils\n/m; }' sed 's|/[^/]*:.*||' missing-eutils.txt | sort -u | while read d; do pushd $d; cvs diff; er "Add inherit eutils" || xterm; popd; done should be done in a couple hours
All done. I also fixed up the eclasses that needed eutils. Between this and bug 49179, extra_functions.sh can now be removed from portage completely. Please do so, otherwise problems will creep back in!
perhaps we can change the extra_functions.sh to call die ... epatch() { die "you need to inherit eutils" } filter-flags() { die "you need to inherit flag-o-matic" }
*** Bug 51107 has been marked as a duplicate of this bug. ***
Just out of curiosity, is there a timetable on this getting repaired in the next portage version? If affects mips because key packages like glibc wind up getting built as -mips1 because any other -mipsX flags get stripped out. If a timetable is unknown, flag-o-matic may have to be altered for mips to avoid stripping the mips-specific flags out.
Kumba, you can workaround by doing "unset ALLOWED_FLAGS" before "inherit flag-o-matic" Carpaski told me that extra_functions.sh would be removed before 2.0.51 release, but it is still in portage cvs.
This is now removed in cvs... and will be removed in future releases.
i need econf in eutils in order to work on the great amd64 multilib migration, but it;s in ebuild.sh....
extra_functions.sh has been punted we're looking at other ways to allow for updates to econf and friends
