From: Brian Harring <ferringb@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
Date: Thu, 20 Oct 2005 18:07:59 -0500 [thread overview]
Message-ID: <20051020230759.GB6127@nightcrawler> (raw)
In-Reply-To: <200510202337.07082.jstubbs@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-10-20 23:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-11 8:05 [gentoo-portage-dev] [PATCH] pre/post phase hooks for users Brian Harring
2005-10-14 16:31 ` Thomas Matthijs
2005-10-14 22:02 ` Brian Harring
2005-10-14 22:05 ` Brian Harring
2005-10-20 14:37 ` Jason Stubbs
2005-10-20 23:07 ` Brian Harring [this message]
2005-10-20 23:43 ` Jason Stubbs
2005-10-21 1:07 ` Brian Harring
2005-10-21 15:19 ` Jason Stubbs
2005-10-26 9:38 ` Thomas Matthijs
2005-10-29 14:34 ` Brian Harring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051020230759.GB6127@nightcrawler \
--to=ferringb@gentoo.org \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox