* [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
@ 2005-10-11 8:05 Brian Harring
2005-10-14 16:31 ` Thomas Matthijs
2005-10-26 9:38 ` Thomas Matthijs
0 siblings, 2 replies; 11+ messages in thread
From: Brian Harring @ 2005-10-11 8:05 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1.1: Type: text/plain, Size: 1400 bytes --]
Since axxo is being a slacker (:-P) and hasn't posted this, did a
quicky implentation for stable ebuild.sh of pre/post phase hooks.
The intention of these hooks are for users to define funcs in their
/etc/portage/bashrc; the phase to be hooked, say pkg_setup , is hooked
via
echo $'
pre_pkg_setup() { echo "I am called prior to pkg_setup"; }
post_pkg_setup() { echo "I am called after pkg_setup"; }
' >> /etc/portage/bashrc
for example.
setup, unpack, compile, test, install, preinst, postinst, prerm,
postrm, and config via this patch have pre/post hooks.
This hooking approach is preferred to just sticking stuff in bashrc
and having it detect the phase- reasoning is that the bashrc will be
sourced once, and only once when ebd is default.
So... it's in users interests to convert over to this setup sooner
rather then later.
Note also, that these hooks aren't phase additions- ebuilds/eclasses
are not to touch them (this will be enforced under ebd also).
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.
Either way, play with it, feedback would be appreciated.
~harring
[-- Attachment #1.2: pre-post-phase-hooks.patch --]
[-- Type: text/plain, Size: 3860 bytes --]
Index: ebuild.sh
===================================================================
--- ebuild.sh (revision 2122)
+++ ebuild.sh (working copy)
@@ -631,11 +631,14 @@
dyn_setup()
{
+ [ "$(type -t pre_pkg_setup)" != "file" ] && pre_pkg_setup
pkg_setup
+ [ "$(type -t post_pkg_setup)" != "file" ] && post_pkg_setup
}
dyn_unpack() {
trap "abort_unpack" SIGINT SIGQUIT
+ [ "$(type -t pre_src_unpack)" != "file" ] && pre_src_unpack
local newstuff="no"
if [ -e "${WORKDIR}" ]; then
local x
@@ -662,6 +665,7 @@
if [ -e "${WORKDIR}" ]; then
if [ "$newstuff" == "no" ]; then
echo ">>> WORKDIR is up-to-date, keeping..."
+ [ "$(type -t post_src_unpack)" != "file" ] && post_src_unpack
return 0
fi
fi
@@ -673,6 +677,9 @@
touch "${BUILDDIR}/.unpacked" || die "IO Failure -- Failed 'touch .unpacked' in BUILDIR"
echo ">>> Source unpacked."
cd "$BUILDDIR"
+
+ [ "$(type -t post_src_unpack)" != "file" ] && post_src_unpack
+
trap SIGINT SIGQUIT
}
@@ -854,6 +861,9 @@
dyn_compile() {
trap "abort_compile" SIGINT SIGQUIT
+
+ [ "$(type -t pre_src_compile)" != "file" ] && pre_src_compile
+
[ "${CFLAGS-unset}" != "unset" ] && export CFLAGS
[ "${CXXFLAGS-unset}" != "unset" ] && export CXXFLAGS
[ "${LIBCFLAGS-unset}" != "unset" ] && export LIBCFLAGS
@@ -892,6 +902,7 @@
echo ">>> It appears that ${PN} is already compiled; skipping."
echo ">>> (clean to force compilation)"
trap SIGINT SIGQUIT
+ [ "$(type -t post_src_compile)" != "file" ] && post_src_compile
return
fi
if [ -d "${S}" ]; then
@@ -948,6 +959,9 @@
if hasq nostrip $FEATURES $RESTRICT; then
touch DEBUGBUILD
fi
+
+ [ "$(type -t post_src_compile)" != "file" ] && post_src_compile
+
trap SIGINT SIGQUIT
}
@@ -972,8 +986,10 @@
dyn_test() {
+ [ "$(type -t pre_src_test)" != "file" ] && pre_src_test
if [ ${BUILDDIR}/.tested -nt "${WORKDIR}" ]; then
echo ">>> It appears that ${PN} has already been tested; skipping."
+ [ "$(type -t post_src_test)" != "file" ] && post_src_test
return
fi
trap "abort_test" SIGINT SIGQUIT
@@ -992,6 +1008,7 @@
cd "${BUILDDIR}"
touch .tested || die "Failed to 'touch .tested' in ${BUILDDIR}"
+ [ "$(type -t post_src_test)" != "file" ] && post_src_test
trap SIGINT SIGQUIT
}
@@ -1001,6 +1018,7 @@
dyn_install() {
trap "abort_install" SIGINT SIGQUIT
+ [ "$(type -t pre_src_install)" != "file" ] && pre_src_install
rm -rf "${BUILDDIR}/image"
mkdir "${BUILDDIR}/image"
if [ -d "${S}" ]; then
@@ -1204,6 +1222,7 @@
echo ">>> Completed installing ${PF} into ${D}"
echo
cd ${BUILDDIR}
+ [ "$(type -t post_src_install)" != "file" ] && post_src_install
trap SIGINT SIGQUIT
}
@@ -1211,6 +1230,8 @@
# set IMAGE depending if this is a binary or compile merge
[ "${EMERGE_FROM}" == "binary" ] && IMAGE=${PKG_TMPDIR}/${PF}/bin \
|| IMAGE=${D}
+
+ [ "$(type -t pre_pkg_preinst)" != "file" ] && pre_pkg_preinst
pkg_preinst
@@ -1319,6 +1340,9 @@
echo "!!! Unable to set SELinux security labels"
fi
fi
+
+ [ "$(type -t post_pkg_preinst)" != "file" ] && post_pkg_preinst
+
trap SIGINT SIGQUIT
}
@@ -1845,11 +1869,15 @@
prerm|postrm|postinst|config)
export SANDBOX_ON="0"
if [ "$PORTAGE_DEBUG" != "1" ]; then
+ [ "$(type -t pre_pkg_${myarg})" != "file" ] && pre_pkg_${myarg}
pkg_${myarg}
+ [ "$(type -t post_pkg_${myarg})" != "file" ] && post_pkg_${myarg}
#Allow non-zero return codes since they can be caused by &&
else
set -x
+ [ "$(type -t pre_pkg_${myarg})" != "file" ] && pre_pkg_${myarg}
pkg_${myarg}
+ [ "$(type -t post_pkg_${myarg})" != "file" ] && post_pkg_${myarg}
#Allow non-zero return codes since they can be caused by &&
set +x
fi
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
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-26 9:38 ` Thomas Matthijs
1 sibling, 1 reply; 11+ messages in thread
From: Thomas Matthijs @ 2005-10-14 16:31 UTC (permalink / raw
To: gentoo-portage-dev
> Index: ebuild.sh
> ===================================================================
> --- ebuild.sh (revision 2122)
> +++ ebuild.sh (working copy)
> @@ -631,11 +631,14 @@
>
> dyn_setup()
> {
> + [ "$(type -t pre_pkg_setup)" != "file" ] && pre_pkg_setup
> pkg_setup
> + [ "$(type -t post_pkg_setup)" != "file" ] && post_pkg_setup
> }
On my system
type -t non-existand-function returns ""
and when it does it gives me "function"
s/!= "file"/== "function"/g ??
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-14 16:31 ` Thomas Matthijs
@ 2005-10-14 22:02 ` Brian Harring
2005-10-14 22:05 ` Brian Harring
0 siblings, 1 reply; 11+ messages in thread
From: Brian Harring @ 2005-10-14 22:02 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 663 bytes --]
On Fri, Oct 14, 2005 at 06:31:45PM +0200, Thomas Matthijs wrote:
> > Index: ebuild.sh
> > ===================================================================
> > --- ebuild.sh (revision 2122)
> > +++ ebuild.sh (working copy)
> > @@ -631,11 +631,14 @@
> >
> > dyn_setup()
> > {
> > + [ "$(type -t pre_pkg_setup)" != "file" ] && pre_pkg_setup
> > pkg_setup
> > + [ "$(type -t post_pkg_setup)" != "file" ] && post_pkg_setup
> > }
>
> On my system
> type -t non-existand-function returns ""
> and when it does it gives me "function"
>
> s/!= "file"/== "function"/g ??
Yah, good catch.
Jason, your thoughts on this 53 wise?
~harring
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-14 22:02 ` Brian Harring
@ 2005-10-14 22:05 ` Brian Harring
2005-10-20 14:37 ` Jason Stubbs
0 siblings, 1 reply; 11+ messages in thread
From: Brian Harring @ 2005-10-14 22:05 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
On Fri, Oct 14, 2005 at 05:02:02PM -0500, Brian Harring wrote:
> On Fri, Oct 14, 2005 at 06:31:45PM +0200, Thomas Matthijs wrote:
> > > Index: ebuild.sh
> > > ===================================================================
> > > --- ebuild.sh (revision 2122)
> > > +++ ebuild.sh (working copy)
> > > @@ -631,11 +631,14 @@
> > >
> > > dyn_setup()
> > > {
> > > + [ "$(type -t pre_pkg_setup)" != "file" ] && pre_pkg_setup
> > > pkg_setup
> > > + [ "$(type -t post_pkg_setup)" != "file" ] && post_pkg_setup
> > > }
> >
> > On my system
> > type -t non-existand-function returns ""
> > and when it does it gives me "function"
> >
> > s/!= "file"/== "function"/g ??
> Yah, good catch.
>
> Jason, your thoughts on this 53 wise?
Bleh, pardon, meant .54 for inclussion
> ~harring
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-14 22:05 ` Brian Harring
@ 2005-10-20 14:37 ` Jason Stubbs
2005-10-20 23:07 ` Brian Harring
0 siblings, 1 reply; 11+ messages in thread
From: Jason Stubbs @ 2005-10-20 14:37 UTC (permalink / raw
To: gentoo-portage-dev
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-20 14:37 ` Jason Stubbs
@ 2005-10-20 23:07 ` Brian Harring
2005-10-20 23:43 ` Jason Stubbs
0 siblings, 1 reply; 11+ messages in thread
From: Brian Harring @ 2005-10-20 23:07 UTC (permalink / raw
To: gentoo-portage-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-20 23:07 ` Brian Harring
@ 2005-10-20 23:43 ` Jason Stubbs
2005-10-21 1:07 ` Brian Harring
0 siblings, 1 reply; 11+ messages in thread
From: Jason Stubbs @ 2005-10-20 23:43 UTC (permalink / raw
To: gentoo-portage-dev
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-20 23:43 ` Jason Stubbs
@ 2005-10-21 1:07 ` Brian Harring
2005-10-21 15:19 ` Jason Stubbs
0 siblings, 1 reply; 11+ messages in thread
From: Brian Harring @ 2005-10-21 1:07 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-21 1:07 ` Brian Harring
@ 2005-10-21 15:19 ` Jason Stubbs
0 siblings, 0 replies; 11+ messages in thread
From: Jason Stubbs @ 2005-10-21 15:19 UTC (permalink / raw
To: gentoo-portage-dev
On Friday 21 October 2005 10:07, Brian Harring wrote:
> On Fri, Oct 21, 2005 at 08:43:49AM +0900, Jason Stubbs wrote:
> > 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.
Ok then. :)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
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-26 9:38 ` Thomas Matthijs
2005-10-29 14:34 ` Brian Harring
1 sibling, 1 reply; 11+ messages in thread
From: Thomas Matthijs @ 2005-10-26 9:38 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 51 bytes --]
Corrected patch
--
Thomas Matthijs (axxo, knu)
[-- Attachment #2: pre-post-phase-hooks.patch --]
[-- Type: text/plain, Size: 3809 bytes --]
Index: ebuild.sh
===================================================================
--- bin/ebuild.sh (revision 2122)
+++ bin/ebuild.sh (working copy)
@@ -631,11 +631,14 @@
dyn_setup()
{
+ [ "$(type -t pre_pkg_setup)" == "function" ] && pre_pkg_setup
pkg_setup
+ [ "$(type -t post_pkg_setup)" == "function" ] && post_pkg_setup
}
dyn_unpack() {
trap "abort_unpack" SIGINT SIGQUIT
+ [ "$(type -t pre_src_unpack)" == "function" ] && pre_src_unpack
local newstuff="no"
if [ -e "${WORKDIR}" ]; then
local x
@@ -662,6 +665,7 @@
if [ -e "${WORKDIR}" ]; then
if [ "$newstuff" == "no" ]; then
echo ">>> WORKDIR is up-to-date, keeping..."
+ [ "$(type -t post_src_unpack)" == "function" ] && post_src_unpack
return 0
fi
fi
@@ -673,6 +677,9 @@
touch "${BUILDDIR}/.unpacked" || die "IO Failure -- Failed 'touch .unpacked' in BUILDIR"
echo ">>> Source unpacked."
cd "$BUILDDIR"
+
+ [ "$(type -t post_src_unpack)" == "function" ] && post_src_unpack
+
trap SIGINT SIGQUIT
}
@@ -854,6 +861,9 @@
dyn_compile() {
trap "abort_compile" SIGINT SIGQUIT
+
+ [ "$(type -t pre_src_compile)" == "function" ] && pre_src_compile
+
[ "${CFLAGS-unset}" != "unset" ] && export CFLAGS
[ "${CXXFLAGS-unset}" != "unset" ] && export CXXFLAGS
[ "${LIBCFLAGS-unset}" != "unset" ] && export LIBCFLAGS
@@ -892,6 +902,7 @@
echo ">>> It appears that ${PN} is already compiled; skipping."
echo ">>> (clean to force compilation)"
trap SIGINT SIGQUIT
+ [ "$(type -t post_src_compile)" == "function" ] && post_src_compile
return
fi
if [ -d "${S}" ]; then
@@ -948,6 +959,9 @@
if hasq nostrip $FEATURES $RESTRICT; then
touch DEBUGBUILD
fi
+
+ [ "$(type -t post_src_compile)" == "function" ] && post_src_compile
+
trap SIGINT SIGQUIT
}
@@ -972,8 +986,10 @@
dyn_test() {
+ [ "$(type -t pre_src_test)" == "function" ] && pre_src_test
if [ ${BUILDDIR}/.tested -nt "${WORKDIR}" ]; then
echo ">>> It appears that ${PN} has already been tested; skipping."
+ [ "$(type -t post_src_test)" == "function" ] && post_src_test
return
fi
trap "abort_test" SIGINT SIGQUIT
@@ -992,6 +1008,7 @@
cd "${BUILDDIR}"
touch .tested || die "Failed to 'touch .tested' in ${BUILDDIR}"
+ [ "$(type -t post_src_test)" == "function" ] && post_src_test
trap SIGINT SIGQUIT
}
@@ -1001,6 +1018,7 @@
dyn_install() {
trap "abort_install" SIGINT SIGQUIT
+ [ "$(type -t pre_src_install)" == "function" ] && pre_src_install
rm -rf "${BUILDDIR}/image"
mkdir "${BUILDDIR}/image"
if [ -d "${S}" ]; then
@@ -1204,6 +1222,7 @@
echo ">>> Completed installing ${PF} into ${D}"
echo
cd ${BUILDDIR}
+ [ "$(type -t post_src_install)" == "function" ] && post_src_install
trap SIGINT SIGQUIT
}
@@ -1211,6 +1230,8 @@
# set IMAGE depending if this is a binary or compile merge
[ "${EMERGE_FROM}" == "binary" ] && IMAGE=${PKG_TMPDIR}/${PF}/bin \
|| IMAGE=${D}
+
+ [ "$(type -t pre_pkg_preinst)" == "function" ] && pre_pkg_preinst
pkg_preinst
@@ -1319,6 +1340,9 @@
echo "!!! Unable to set SELinux security labels"
fi
fi
+
+ [ "$(type -t post_pkg_preinst)" == "function" ] && post_pkg_preinst
+
trap SIGINT SIGQUIT
}
@@ -1845,11 +1869,15 @@
prerm|postrm|postinst|config)
export SANDBOX_ON="0"
if [ "$PORTAGE_DEBUG" != "1" ]; then
+ [ "$(type -t pre_pkg_${myarg})" == "function" ] && pre_pkg_${myarg}
pkg_${myarg}
+ [ "$(type -t post_pkg_${myarg})" == "function" ] && post_pkg_${myarg}
#Allow non-zero return codes since they can be caused by &&
else
set -x
+ [ "$(type -t pre_pkg_${myarg})" == "function" ] && pre_pkg_${myarg}
pkg_${myarg}
+ [ "$(type -t post_pkg_${myarg})" == "function" ] && post_pkg_${myarg}
#Allow non-zero return codes since they can be caused by &&
set +x
fi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
2005-10-26 9:38 ` Thomas Matthijs
@ 2005-10-29 14:34 ` Brian Harring
0 siblings, 0 replies; 11+ messages in thread
From: Brian Harring @ 2005-10-29 14:34 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 4618 bytes --]
On Wed, Oct 26, 2005 at 11:38:00AM +0200, Thomas Matthijs wrote:
If you're doing up a 53_rc7, I'd be curious if anyone is going to have
issues with this one sliding into .53; it's a shoe in for .54 (it's
bloody simple, mainly), but .54 is going to be a ways out, and this is
useful _now_ for ebuild devs.
Yay/nay?
~harring
> Corrected patch
>
> --
> Thomas Matthijs (axxo, knu)
> Index: ebuild.sh
> ===================================================================
> --- bin/ebuild.sh (revision 2122)
> +++ bin/ebuild.sh (working copy)
> @@ -631,11 +631,14 @@
>
> dyn_setup()
> {
> + [ "$(type -t pre_pkg_setup)" == "function" ] && pre_pkg_setup
> pkg_setup
> + [ "$(type -t post_pkg_setup)" == "function" ] && post_pkg_setup
> }
>
> dyn_unpack() {
> trap "abort_unpack" SIGINT SIGQUIT
> + [ "$(type -t pre_src_unpack)" == "function" ] && pre_src_unpack
> local newstuff="no"
> if [ -e "${WORKDIR}" ]; then
> local x
> @@ -662,6 +665,7 @@
> if [ -e "${WORKDIR}" ]; then
> if [ "$newstuff" == "no" ]; then
> echo ">>> WORKDIR is up-to-date, keeping..."
> + [ "$(type -t post_src_unpack)" == "function" ] && post_src_unpack
> return 0
> fi
> fi
> @@ -673,6 +677,9 @@
> touch "${BUILDDIR}/.unpacked" || die "IO Failure -- Failed 'touch .unpacked' in BUILDIR"
> echo ">>> Source unpacked."
> cd "$BUILDDIR"
> +
> + [ "$(type -t post_src_unpack)" == "function" ] && post_src_unpack
> +
> trap SIGINT SIGQUIT
> }
>
> @@ -854,6 +861,9 @@
>
> dyn_compile() {
> trap "abort_compile" SIGINT SIGQUIT
> +
> + [ "$(type -t pre_src_compile)" == "function" ] && pre_src_compile
> +
> [ "${CFLAGS-unset}" != "unset" ] && export CFLAGS
> [ "${CXXFLAGS-unset}" != "unset" ] && export CXXFLAGS
> [ "${LIBCFLAGS-unset}" != "unset" ] && export LIBCFLAGS
> @@ -892,6 +902,7 @@
> echo ">>> It appears that ${PN} is already compiled; skipping."
> echo ">>> (clean to force compilation)"
> trap SIGINT SIGQUIT
> + [ "$(type -t post_src_compile)" == "function" ] && post_src_compile
> return
> fi
> if [ -d "${S}" ]; then
> @@ -948,6 +959,9 @@
> if hasq nostrip $FEATURES $RESTRICT; then
> touch DEBUGBUILD
> fi
> +
> + [ "$(type -t post_src_compile)" == "function" ] && post_src_compile
> +
> trap SIGINT SIGQUIT
> }
>
> @@ -972,8 +986,10 @@
>
>
> dyn_test() {
> + [ "$(type -t pre_src_test)" == "function" ] && pre_src_test
> if [ ${BUILDDIR}/.tested -nt "${WORKDIR}" ]; then
> echo ">>> It appears that ${PN} has already been tested; skipping."
> + [ "$(type -t post_src_test)" == "function" ] && post_src_test
> return
> fi
> trap "abort_test" SIGINT SIGQUIT
> @@ -992,6 +1008,7 @@
>
> cd "${BUILDDIR}"
> touch .tested || die "Failed to 'touch .tested' in ${BUILDDIR}"
> + [ "$(type -t post_src_test)" == "function" ] && post_src_test
> trap SIGINT SIGQUIT
> }
>
> @@ -1001,6 +1018,7 @@
>
> dyn_install() {
> trap "abort_install" SIGINT SIGQUIT
> + [ "$(type -t pre_src_install)" == "function" ] && pre_src_install
> rm -rf "${BUILDDIR}/image"
> mkdir "${BUILDDIR}/image"
> if [ -d "${S}" ]; then
> @@ -1204,6 +1222,7 @@
> echo ">>> Completed installing ${PF} into ${D}"
> echo
> cd ${BUILDDIR}
> + [ "$(type -t post_src_install)" == "function" ] && post_src_install
> trap SIGINT SIGQUIT
> }
>
> @@ -1211,6 +1230,8 @@
> # set IMAGE depending if this is a binary or compile merge
> [ "${EMERGE_FROM}" == "binary" ] && IMAGE=${PKG_TMPDIR}/${PF}/bin \
> || IMAGE=${D}
> +
> + [ "$(type -t pre_pkg_preinst)" == "function" ] && pre_pkg_preinst
>
> pkg_preinst
>
> @@ -1319,6 +1340,9 @@
> echo "!!! Unable to set SELinux security labels"
> fi
> fi
> +
> + [ "$(type -t post_pkg_preinst)" == "function" ] && post_pkg_preinst
> +
> trap SIGINT SIGQUIT
> }
>
> @@ -1845,11 +1869,15 @@
> prerm|postrm|postinst|config)
> export SANDBOX_ON="0"
> if [ "$PORTAGE_DEBUG" != "1" ]; then
> + [ "$(type -t pre_pkg_${myarg})" == "function" ] && pre_pkg_${myarg}
> pkg_${myarg}
> + [ "$(type -t post_pkg_${myarg})" == "function" ] && post_pkg_${myarg}
> #Allow non-zero return codes since they can be caused by &&
> else
> set -x
> + [ "$(type -t pre_pkg_${myarg})" == "function" ] && pre_pkg_${myarg}
> pkg_${myarg}
> + [ "$(type -t post_pkg_${myarg})" == "function" ] && post_pkg_${myarg}
> #Allow non-zero return codes since they can be caused by &&
> set +x
> fi
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-10-29 14:35 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox