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 1Sd4wE-0002x4-3m for garchives@archives.gentoo.org; Fri, 08 Jun 2012 19:33:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1012D21C039; Fri, 8 Jun 2012 19:33:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 6D39721C033 for ; Fri, 8 Jun 2012 19:31:56 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id D395E1B4016 for ; Fri, 8 Jun 2012 19:31:55 +0000 (UTC) Message-ID: <4FD2532B.4030506@gentoo.org> Date: Fri, 08 Jun 2012 12:31:55 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:13.0) Gecko/20120607 Thunderbird/13.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue 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> <20120607184008.09aca0fe@googlemail.com> <4FD0ECED.10201@gentoo.org> <1339092995.3014.23.camel@belkin4> <1339094634.3014.24.camel@belkin4> <20120607194448.1577119e@googlemail.com> <1339095641.3014.26.camel@belkin4> <4FD0FC81.9070701@gentoo.org> <1339097086.3014.28.camel@belkin4> <4FD101EC.7080306@gentoo.org> <1339144721.4179.1.camel@belkin4> <4FD24F73.8000601@gentoo.org> <1339183412.4179.30.camel@belkin4> In-Reply-To: <1339183412.4179.30.camel@belkin4> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 78859079-e2be-429e-af7d-7965d14f1676 X-Archives-Hash: fcfc710847a4d3086c3fd7596fbe20b8 On 06/08/2012 12:23 PM, Pacho Ramos wrote: > El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribi=C3=B3: >> On 06/08/2012 01:38 AM, Pacho Ramos wrote: >>> El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribi=C3=B3: >>>> On 06/07/2012 12:24 PM, Pacho Ramos wrote: >>>>> El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribi=C3=B3: >>>>>> On 06/07/2012 12:00 PM, Pacho Ramos wrote: >>>>>>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribi=C3=B3= : >>>>>>>> On Thu, 07 Jun 2012 20:43:54 +0200 >>>>>>>> Pacho Ramos wrote: >>>>>>>>>> I would prefer, as a workaround, allow reverse deps to RDEPEND= on >>>>>>>>>> glib:2.* instead. That way it would cover more cases when more= than >>>>>>>>>> two slots are available >>>>>>>>> >>>>>>>>> Well, per: >>>>>>>>> http://git.overlays.gentoo.org/gitweb/?p=3Dproj/pms.git;a=3Dcom= mitdiff;h=3Df9f7729c047300e1924ad768a49c660e12c2f906;hp=3Db7750e67b4772c1= 064543defb7df6a556f09807b >>>>>>>>> >>>>>>>>> looks like "*" usage for SLOTs would be allowed :), or I am >>>>>>>>> misinterpreting it? >>>>>>>> >>>>>>>> It's not a wildcard. >>>>>>>> >>>>>>> >>>>>>> But it looks like a valid usage for cases like glib vs. >>>>>>> dbus-glib/gobject-introspection I have exposed as example, and al= so >>>>>>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this case,= not >>>>>>> sure about others I could be missing now...) >>>>>> >>>>>> The :* operator doesn't trigger any rebuilds though. Quoting the P= MS >>>>>> patch that you linked: >>>>>> >>>>>> * Indicates that any slot value is acceptable. In addition, for ru= ntime >>>>>> dependencies, indicates that the package will not break if the mat= ched >>>>>> package is uninstalled and replaced by a different matching packag= e in a >>>>>> different slot. >>>>> >>>>> I mean, use it in conjunction with ":=3D", one for rebuild and othe= r to >>>>> indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to >>>>> periodically update RDEPENDs or need to go back from :SLOT depends = to >>>>> old =3Dcategory/package-version-* ways) >>>>> >>>>> Allowing that, we wouldn't need ABI_SLOT (at least to prevent this = issue >>>>> that arises with using only SLOTs for this) >>>> >>>> What you're talking about here is more similar to ABI_SLOT operator = deps >>>> than what was originally intended for SLOT operator deps. In other >>>> words, anyone who is opposed to ABI_SLOT operator deps is likely to = also >>>> be opposed to your proposal. >>> >>> Oh :(, and what is the reason to want to prevent this behavior? Looks >>> much simpler to me than needing to use ranges for dependencies or >>> needing to create "compat" packages to hide the problem :| >> >> It's close enough to ABI_SLOT that it would make more sense just to us= e >> ABI_SLOT because it's more flexible. >=20 > In that case, I think it's clear we need ABI_SLOT ;) The problem is how > to document it in a way people agree with including it for eapi5 :| We can just write a specification for this one feature, and ask the Council to approve it. --=20 Thanks, Zac