Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 167029 - ruby.eclass prepall override needs to be removed.
Summary: ruby.eclass prepall override needs to be removed.
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Ruby Team
Depends on:
Reported: 2007-02-15 14:06 UTC by Brian Harring (RETIRED)
Modified: 2014-07-06 08:10 UTC (History)
4 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Brian Harring (RETIRED) gentoo-dev 2007-02-15 14:06:05 UTC
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 :)
Comment 1 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2007-03-31 18:15:54 UTC
Do you have any suggestion? I'm not familiar with ruby.eclass, shouldn't promise anything..
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2007-05-17 16:42:19 UTC
Also, messing with shell options without restoring the original values is pretty uncool...

 * QA Notice: Global shell options changed and were not restored while calling 'pkg_postrm'
Comment 3 Mark Loeser (RETIRED) gentoo-dev 2007-12-23 06:05:55 UTC
So, what's going on with this one guys?
Comment 4 Hans de Graaff gentoo-dev 2007-12-23 14:11:03 UTC
(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.
Comment 5 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-12-14 13:44:40 UTC
The replacement eclass ruby-ng.eclass is now in the tree.
Next step: Migrating all ebuilds
Comment 6 Hans de Graaff gentoo-dev 2010-08-22 08:23:37 UTC
Status update: all packages have been converted to the new eclasses.

Next step is to stable all packages that still use the old eclasses.
Comment 7 Manuel Rüger (RETIRED) gentoo-dev 2014-07-04 02:03:07 UTC
ruby.eclass has been removed. Is this bug still necessary?