1 |
On Friday 21 October 2005 10:07, Brian Harring wrote: |
2 |
> On Fri, Oct 21, 2005 at 08:43:49AM +0900, Jason Stubbs wrote: |
3 |
> > I don't get why it's "needed" by java ebuilds? Is it a fasttrack to |
4 |
> > getting unsandboxed root access? |
5 |
> |
6 |
> Env var preservation against portage stomp of the vars. java vars in |
7 |
> /etc/profile.env automatically stomp the re-loaded env per phase, to |
8 |
> fix this you need either |
9 |
> |
10 |
> A) ebd with it's env saving/restoration |
11 |
> B1) ebuilds to reset those vars for every phase |
12 |
> B2) modify 700 ebuilds so they call this new func. |
13 |
> C1) eclass that defines it's own funcs, src_unpack() { reset_vars; |
14 |
> jc_src_unpack; } C2) Modify the couple hundred ebuilds that define *any* of |
15 |
> the phase funcs. C3) Work out the compatibility nightmare when dealing with |
16 |
> other eclasses D) Add a user feature (bonus for users), and have java |
17 |
> eclasses abuse it (including warnings), allowing the env fix to be deployed |
18 |
> without mangling ebuilds, and automatically disabled when the |
19 |
> executing portage is ebd based. |
20 |
> |
21 |
> Granted... I laid it on thick, but D is the cleanest solution that |
22 |
> solves it now providing a useful user feature, and covering up a major |
23 |
> issue for java 1.4 -> java 1.5 support ebuild wise, without modifying |
24 |
> 700 ebuilds. |
25 |
> |
26 |
> Clarifying... I have no intention of expanding the phases, this is |
27 |
> intended to be strictly user hooks, with the exception that java |
28 |
> eclasses can abuse it right now (no other choice) till 3.0. |
29 |
> With the java scenario, disabling the env reset (abuse of user hooks) |
30 |
> works perfectly; under 3.0, they don't _need_ the env reset. |
31 |
|
32 |
Ok then. :) |
33 |
|
34 |
-- |
35 |
Jason Stubbs |
36 |
-- |
37 |
gentoo-portage-dev@g.o mailing list |