From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GfumB-0006OC-Fs for garchives@archives.gentoo.org; Fri, 03 Nov 2006 08:51:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kA38orp7026878; Fri, 3 Nov 2006 08:50:53 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kA38mZoD026901 for ; Fri, 3 Nov 2006 08:48:36 GMT Received: from [192.168.24.6] (ip68-5-234-231.oc.oc.cox.net [68.5.234.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 6734964BB6 for ; Fri, 3 Nov 2006 08:48:35 +0000 (UTC) Message-ID: <454B014A.8070203@gentoo.org> Date: Fri, 03 Nov 2006 00:43:54 -0800 From: Zac Medico User-Agent: Thunderbird 1.5.0.7 (X11/20060909) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior References: <200611030229.46220.vapier@gentoo.org> In-Reply-To: <200611030229.46220.vapier@gentoo.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------040401090300060002040001" X-Archives-Salt: 946894e0-db82-4867-bc11-ea17b4d81e5c X-Archives-Hash: e0b15e8c421d069be705487eade7384f This is a multi-part message in MIME format. --------------040401090300060002040001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----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----- --------------040401090300060002040001 Content-Type: text/plain; name="revert_to_2.0.51_rdepend.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="revert_to_2.0.51_rdepend.patch" SW5kZXg6IGJpbi9lYnVpbGQuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmluL2VidWlsZC5zaAko cmV2aXNpb24gNDkxMykKKysrIGJpbi9lYnVpbGQuc2gJKHdvcmtpbmcgY29weSkKQEAgLTE1 MDQsOCArMTUwNCw4IEBACiAjc3ludGF4IGZyb20gZ2V0dGluZyBleHBhbmRlZCA6KQogI2No ZWNrIGVjbGFzcyByZGVwZW5kcyBhbHNvLgogc2V0IC1mCi1pZiBbICIke1JERVBFTkQtdW5z ZXR9IiA9PSAidW5zZXQiIF0gJiYgWyAiJHtFX1JERVBFTkQtdW5zZXR9IiA9PSAidW5zZXQi IF0gOyB0aGVuCi0JZXhwb3J0IFJERVBFTkQ9IiR7REVQRU5EfSAke0VfREVQRU5EfSIKK2lm IFsgIiR7UkRFUEVORC11bnNldH0iID09ICJ1bnNldCIgXTsgdGhlbgorCWV4cG9ydCBSREVQ RU5EPSR7REVQRU5EfQogCWRlYnVnLXByaW50ICJSREVQRU5EOiBub3Qgc2V0Li4uIFNldHRp bmcgdG86ICR7REVQRU5EfSIKIGZpCiAK --------------040401090300060002040001-- -- gentoo-dev@gentoo.org mailing list