I'll grant y'all, it's an interesting trick- few problems with it though. 1) src_compile, src_unpack phases exist for a reason- that specific work should be undertaken then. 2) said phases have differing rules for lock down. Install is actually the least restricted- compile, unpack, don't require the ability to create root files (exempting the affects of RESTRICT=(userpriv|sandbox) of course), thus can be deprived. without heavy expansion of metadata (or running install under fakeroot, which has it's own issues), install must remain the high prived phase. 3) you're overriding what is effectively a package manager specific internal. Basically, eclasses can be used with any portage version- that prepall can be invoked by portage 2.2, portage 2.1, even portage 2.0.54- the prepall can *vary* between those versions providing new functionality. Via overriding, y'all have to reimplement it in the tree, meaning you either have to detect the manager version and turn on differing functionality, try to match the current stable manager (horrible idea), or forego trying to match it (again, kind of horrible). Simple example of the latter is the lack of chflags bits. So... it's a bad idea from a maintenance standpoint, and it inherintly disables protections built in when executed. Realize there are 187 packages consuming this eclass, and that it requires a significant restructuring, but... it is required :)
Do you have any suggestion? I'm not familiar with ruby.eclass, shouldn't promise anything..
Also, messing with shell options without restoring the original values is pretty uncool... <snip> * QA Notice: Global shell options changed and were not restored while calling 'pkg_postrm' </snip>
So, what's going on with this one guys?
(In reply to comment #3) > So, what's going on with this one guys? Nothing :-( No one from the current ruby herd knows the ins and outs of ruby.eclass, and we have barely enough man-power atm to keep up with security issues and requested version bumps, so no-one has been able to dive into this eclass and fix up things. I assume we'll have to visit the eclass shortly anyway because of the forthcoming ruby 1.9, so perhaps we can tackle this issue at the same time.
The replacement eclass ruby-ng.eclass is now in the tree. Next step: Migrating all ebuilds
Status update: all packages have been converted to the new eclasses. Next step is to stable all packages that still use the old eclasses.
ruby.eclass has been removed. Is this bug still necessary?
