From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Sch5y-0003hy-MV for garchives@archives.gentoo.org; Thu, 07 Jun 2012 18:06:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 312B4E0752; Thu, 7 Jun 2012 18:05:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CE814E070C for ; Thu, 7 Jun 2012 18:04:23 +0000 (UTC) Received: from sera-17.lan (101-108.79-83.cust.bluewin.ch [83.79.108.101]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sera) by smtp.gentoo.org (Postfix) with ESMTPSA id B05C71B4028 for ; Thu, 7 Jun 2012 18:04:22 +0000 (UTC) Date: Thu, 7 Jun 2012 20:04:04 +0200 From: Ralph Sennhauser To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue Message-ID: <20120607200404.66cd3dbd@sera-17.lan> In-Reply-To: <4FD0DA34.8080409@gentoo.org> References: <4FCF2012.3040500@gentoo.org> <1338976106.2706.36.camel@belkin4> <20120606181650.0c727f18@googlemail.com> <1339005744.2706.47.camel@belkin4> <20120606191505.4e011158@googlemail.com> <1339007452.2706.57.camel@belkin4> <20120606193348.67b83427@googlemail.com> <1339010165.2706.62.camel@belkin4> <20120606202340.6c95711f@googlemail.com> <4FCFF945.1070804@gentoo.org> <20120607082409.GB3352@localhost.google.com> <4FD0DA34.8080409@gentoo.org> Organization: Gentoo Linux X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3UAn65Lu.t/q2YXuchr/ROn"; protocol="application/pgp-signature" X-Archives-Salt: 8f93e9d4-4b6c-4e30-899b-51bd17b4daaf X-Archives-Hash: bbf9fe976f1d5b86e727c4246ce6cf35 --Sig_/3UAn65Lu.t/q2YXuchr/ROn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico wrote: > On 06/07/2012 01:24 AM, Brian Harring wrote: > > On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: > >> On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > >>> On Wed, 06 Jun 2012 21:16:05 +0200 > >>> Pacho Ramos wrote: > >>>> Well, I think reading this thread is more or less clear what it > >>>> would be supposed to do, also Zac suggested it and looks to have > >>>> an idea about what should it do. > >>> > >>> There's a big leap from "more or less clear" and "an idea" to the > >>> kind of knowledge we want to have. Think REQUIRED_USE for how > >>> this can go wrong... > >>> > >>> If you think ABI_SLOT is essential, why not try implementing it > >>> and trying it out in a large number of packages, and reporting > >>> your results? > >> > >> It's pretty close to the SLOT operator model, and it seems like it > >> should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, > >> and test it in an overlay before we include it in the final EAPI 5. > >=20 > > I'd prefer you nailing down the details a bit more before slipping > > it into an EAPI called "5_pre1"; aside from usual complaints, > > frankly I'd rather not have to figure out the design of it via > > raiding the patches out of portage history ;) >=20 > Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe > we can convince him to change it to ABI_SLOT operators. >=20 Whether we can convince Ciaran to change the wording of a feature in a draft document is utterly irrelevant. SLOT operator deps solve a large class of issues and wont get in the way of solving the ranged dep problem in a later step, be it ABI_SLOT or something more generic. I'm all for getting SLOT operators into EAPI-5 as actually already intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so don't let us delay the whole thing because of that. > > If we're going to do this, there should be a way to represent=20 > > the direction of compatibility. Might be overthinking it, but=20 > > consider upgrades where new API is added; this does *not* break > > ABI, it extends it. Going in reverse however *would* break ABI for=20 > > anything that was using the new additions. This issue can be > > avoided via usage of version operators w/ appropriate slot binding > > deps, just seems hanky in light of what we're talking about. >=20 > That might be nice, but it also complicates things a bit. We might > stand a better chance of getting Ciaran to cooperate if we keep it > simpler and stay closer to the SLOT operator model. >=20 Again, it's not about getting someone to cooperate. Something that you comment with "that might be nice" isn't ready for inclusion into EAPI 5. > > I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing > > in '06/'07); I'd however suggest ensuring there is some buy in from > > devs on that one since that was the main argument against it in the > > past. >=20 > I can imagine that ABI_SLOT operator deps will be a lot more popular > than SLOT operator deps, since ABI_SLOT operator deps will accommodate > the common practice of allowing ABI changes within a particular SLOT. What for? So we won't ever get rid of revdep-rebuild resp. @preserved-libs? Except for the ranged dep problem I don't see any additional benefit but potential drawbacks. Please correct me where I'm wrong. Cheers. --Sig_/3UAn65Lu.t/q2YXuchr/ROn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBAgAGBQJP0O0gAAoJEIUJ+svaV163qCcH/3jOzeXqdQbthq+6JJd9e+fU CBPvJHzVZ7fSF3Rm0WlnsT7+5U3ciw6qSBMWObnKu9PismwNpLFzdnJlBw4A0HuZ kCMCol8rokBn776NyJAOHT0FmkFFpE8HqKA3adaGDCukm+Q90bKfLlHvAtaobS1g pvRZPAq7l7Y/jGjIhNJw6pTEU416FHfnIckZq68pHV1vwy7E4zXxTw1PXGf0NTN5 +LCNqYYzuhRZPXcI8cWIkWFHvV17NjfTIf5Xs6dTBrzGjSFmT+rqPyTZM2jsr5A7 /FnJCImWTUqmDLXPBndBKYsAp979/lfF69ATKaxQPsqFy4UknjER1WXrpOG7Myo= =y+Xz -----END PGP SIGNATURE----- --Sig_/3UAn65Lu.t/q2YXuchr/ROn--