Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users

[Brian Harring]

On Fri, Oct 21, 2005 at 08:43:49AM +0900, Jason Stubbs wrote:
> On Friday 21 October 2005 08:07, Brian Harring wrote:
> > Bash hooks would exist in 3.0; they're user specific hooks only, hence
> > the bit about java being an evil exception till 3.0 comes to town.  I
> > intend to lock down the pre/post hooks prior to ebuild sourcing under
> > ebd, so ebuilds/eclasses trying to use those hooks won't be able to.
> >
> > In the meantime, it's a nice abuse of a user feature that makes java
> > 1.4->1.5 stuff work, and works fine when 3.0 autodisables it.
>
> I don't get why it's "needed" by java ebuilds? Is it a fasttrack to getting
> unsandboxed root access?
Env var preservation against portage stomp of the vars.  java vars in 
/etc/profile.env automatically stomp the re-loaded env per phase, to 
fix this you need either

A) ebd with it's env saving/restoration
B1) ebuilds to reset those vars for every phase
B2) modify 700 ebuilds so they call this new func.
C1) eclass that defines it's own funcs, src_unpack() { reset_vars; jc_src_unpack; }
C2) Modify the couple hundred ebuilds that define *any* of the phase funcs.
C3) Work out the compatibility nightmare when dealing with other eclasses
D) Add a user feature (bonus for users), and have java eclasses abuse 
   it (including warnings), allowing the env fix to be deployed 
   without mangling ebuilds, and automatically disabled when the 
   executing portage is ebd based.

Granted... I laid it on thick, but D is the cleanest solution that 
solves it now providing a useful user feature, and covering up a major 
issue for java 1.4 -> java 1.5 support ebuild wise, without modifying 
700 ebuilds.

Clarifying... I have no intention of expanding the phases, this is 
intended to be strictly user hooks, with the exception that java 
eclasses can abuse it right now (no other choice) till 3.0.
With the java scenario, disabling the env reset (abuse of user hooks) 
works perfectly; under 3.0, they don't _need_ the env reset.
~harring