-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Frysinger wrote:
> this is not a "implicit vs explicit" thread; if you want that discussion
> start
> your own
>
> we've said the relationship of DEPEND atoms in ebuilds should be independent
> of the DEPEND atoms found in eclasses as logically ebuilds should not care
> what it takes for eclasses to work and vice versa ... for the most part, this
> is true ...
>
> however, semi-recently, a change was made such that the implicit
> RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in
> any way ... that means if you have an ebuild at the moment that does:
> DEPEND="foo"
> and you dont inherit any eclasses, then you also get for free:
> RDEPEND="foo"
The change occurred sometime between portage-2.0.51 and portage-2.0.52, and the
first stable version to have it was portage-2.0.53 (released in December of
2005). People didn't really start to notice the difference until after
portage-2.1 had been deployed on the master rsync mirror last June (it had been
running portage-2.0.51.22-r3 up until then).
> if you decide to inherit eclasses though, you had better do some research as
> any eclass that does even RDEPEND="" will change that behavior ... or if you
> are an eclass writer and you decided to add RDEPEND to your eclass, you had
> better do a reverse check and make sure that any ebuild that inherits your
> eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as
> you would have just broken it ... awesome ;)
>
> i posted a patch to fix this regression, but since it took so long before
> anyone noticed, zmedico wants to see if anyone is opposed (i dont know why
> they would be, but i cant think of everything)
>
> so to recap, the fix here changes it back to the historically documented
> behavior that the implicit RDEPEND happens in ebuilds regardless of what
> eclasses do
> -mike
If we do this then I want to make sure everybody is prepared for the
consequences. Basically, it restricts implicit RDEPEND to the ebuild level,
making it independent of whatever RDEPEND may or may not be defined in the
inherited eclasses. That means that some ebuilds will get implicit RDEPEND
that they don't get currently. Also, some ebuilds will loose some implicit
RDEPEND that they current get from eclasses.
I've attached the patch which reverts the behavior. If we do this, I think that
we should do it in one big sweep, via a sys-apps/portage revbump and a
simultaneous application of the patch on the master rsync mirror (see Brian
Harring's email for more details).
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFSwFI/ejvha5XGaMRArjaAKDi8B++F71vt3D2QkG5vyRhZ0yWvgCghBVA
ZrVSROlN0E7X/xdkFbJ6NXo=
=yRsF
-----END PGP SIGNATURE-----
Index: bin/ebuild.sh
===================================================================
--- bin/ebuild.sh (revision 4913)
+++ bin/ebuild.sh (working copy)
@@ -1504,8 +1504,8 @@
#syntax from getting expanded :)
#check eclass rdepends also.
set -f
-if [ "${RDEPEND-unset}" == "unset" ] && [ "${E_RDEPEND-unset}" == "unset" ] ;
then
- export RDEPEND="${DEPEND} ${E_DEPEND}"
+if [ "${RDEPEND-unset}" == "unset" ]; then
+ export RDEPEND=${DEPEND}
debug-print "RDEPEND: not set... Setting to: ${DEPEND}"
fi
