Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
Date: Fri, 03 Nov 2006 08:51:47
Message-Id: 454B014A.8070203@gentoo.org
In Reply to: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior by Mike Frysinger
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Mike Frysinger wrote:
5 > this is not a "implicit vs explicit" thread; if you want that discussion start
6 > your own
7 >
8 > we've said the relationship of DEPEND atoms in ebuilds should be independent
9 > of the DEPEND atoms found in eclasses as logically ebuilds should not care
10 > what it takes for eclasses to work and vice versa ... for the most part, this
11 > is true ...
12 >
13 > however, semi-recently, a change was made such that the implicit
14 > RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in
15 > any way ... that means if you have an ebuild at the moment that does:
16 > DEPEND="foo"
17 > and you dont inherit any eclasses, then you also get for free:
18 > RDEPEND="foo"
19
20 The change occurred sometime between portage-2.0.51 and portage-2.0.52, and the
21 first stable version to have it was portage-2.0.53 (released in December of
22 2005). People didn't really start to notice the difference until after
23 portage-2.1 had been deployed on the master rsync mirror last June (it had been
24 running portage-2.0.51.22-r3 up until then).
25
26 > if you decide to inherit eclasses though, you had better do some research as
27 > any eclass that does even RDEPEND="" will change that behavior ... or if you
28 > are an eclass writer and you decided to add RDEPEND to your eclass, you had
29 > better do a reverse check and make sure that any ebuild that inherits your
30 > eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as
31 > you would have just broken it ... awesome ;)
32 >
33 > i posted a patch to fix this regression, but since it took so long before
34 > anyone noticed, zmedico wants to see if anyone is opposed (i dont know why
35 > they would be, but i cant think of everything)
36 >
37 > so to recap, the fix here changes it back to the historically documented
38 > behavior that the implicit RDEPEND happens in ebuilds regardless of what
39 > eclasses do
40 > -mike
41
42 If we do this then I want to make sure everybody is prepared for the
43 consequences. Basically, it restricts implicit RDEPEND to the ebuild level,
44 making it independent of whatever RDEPEND may or may not be defined in the
45 inherited eclasses. That means that some ebuilds will get implicit RDEPEND
46 that they don't get currently. Also, some ebuilds will loose some implicit
47 RDEPEND that they current get from eclasses.
48
49 I've attached the patch which reverts the behavior. If we do this, I think that
50 we should do it in one big sweep, via a sys-apps/portage revbump and a
51 simultaneous application of the patch on the master rsync mirror (see Brian
52 Harring's email for more details).
53
54 Zac
55
56 -----BEGIN PGP SIGNATURE-----
57 Version: GnuPG v1.4.5 (GNU/Linux)
58
59 iD8DBQFFSwFI/ejvha5XGaMRArjaAKDi8B++F71vt3D2QkG5vyRhZ0yWvgCghBVA
60 ZrVSROlN0E7X/xdkFbJ6NXo=
61 =yRsF
62 -----END PGP SIGNATURE-----

Attachments

File name MIME type
revert_to_2.0.51_rdepend.patch text/plain

Replies