Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
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
pgpbC2aVXruMy.pgp
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
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? -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
On Thu, Oct 20, 2005 at 11:37:07PM +0900, Jason Stubbs wrote: > On Saturday 15 October 2005 07:05, Brian Harring wrote: > > On Fri, Oct 14, 2005 at 05:02:02PM -0500, Brian Harring wrote: > > > Jason, your thoughts on this 53 wise? > > > > Bleh, pardon, meant .54 for inclussion > > Just to be sure it's clear to everybody (although I think Brian knows > already), my job is not to approve or disapprove of any particular change to > any particular release. If you want to put a title on it, it'd simply be > called "release executor". Hence, the answer to the above question really > lies in the outcome of the .54 thread. The only small perk is that any > suggestions I might have on the release process are quick to be > integrated. ;) Yah I know, but it still is fun punting stuff past you since my normal inclination portage wise, is for things to be a bit raw (progress baby). ;) > On Tuesday 11 October 2005 17:05, Brian Harring wrote: > > That said, their will be an exemption for java ebuilds due to the fact > > that they're blocked by ebuild.sh env handling- they need ebd for > > things to work properly, and in the meantime this gives them a method > > to have things work properly. Downside is that the pre/post hooks are > > not available for users for java ebuilds. > > Why exactly would their be an exemption for java ebuilds? Are the hooks > intended to be used with ebuild packaging as well as by users? Wouldn't new > or altered phases serve ebuild packaging better? If it is for ebuild > packaging, wouldn't the EAPI need to change? If it's not for ebuild > packaging, again why the exemption? > > On the user side of things, will the hooks continue on into later versions? > Specifically, with 3.0 supporting hooks on the python side will the bash > hooks be deprecated? It seems reasonable that both can coexist nicely, so > this is more just confirmation then anything. 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. Regarding EAPI, since it's user specific feature, no need; java ebuilds will have to depend on a portage version capable of the hooks however. ~harring pgpf7MqEaMeFO.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
On Saturday 15 October 2005 07:05, Brian Harring wrote: > On Fri, Oct 14, 2005 at 05:02:02PM -0500, Brian Harring wrote: > > Jason, your thoughts on this 53 wise? > > Bleh, pardon, meant .54 for inclussion Just to be sure it's clear to everybody (although I think Brian knows already), my job is not to approve or disapprove of any particular change to any particular release. If you want to put a title on it, it'd simply be called "release executor". Hence, the answer to the above question really lies in the outcome of the .54 thread. The only small perk is that any suggestions I might have on the release process are quick to be integrated. ;) So, if it's just my input that is being sought after I do have a couple of concerns, specifically related to this bit below: On Tuesday 11 October 2005 17:05, Brian Harring wrote: > That said, their will be an exemption for java ebuilds due to the fact > that they're blocked by ebuild.sh env handling- they need ebd for > things to work properly, and in the meantime this gives them a method > to have things work properly. Downside is that the pre/post hooks are > not available for users for java ebuilds. Why exactly would their be an exemption for java ebuilds? Are the hooks intended to be used with ebuild packaging as well as by users? Wouldn't new or altered phases serve ebuild packaging better? If it is for ebuild packaging, wouldn't the EAPI need to change? If it's not for ebuild packaging, again why the exemption? On the user side of things, will the hooks continue on into later versions? Specifically, with 3.0 supporting hooks on the python side will the bash hooks be deprecated? It seems reasonable that both can coexist nicely, so this is more just confirmation then anything. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
