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 1SdJJg-0000wt-9u for garchives@archives.gentoo.org; Sat, 09 Jun 2012 10:54:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46FB7E011E; Sat, 9 Jun 2012 10:54:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E010B21C027 for ; Sat, 9 Jun 2012 10:53:36 +0000 (UTC) Received: from [192.168.1.204] (23.155.16.95.dynamic.jazztel.es [95.16.155.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 7F31A1B4057 for ; Sat, 9 Jun 2012 10:53:35 +0000 (UTC) Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue From: Pacho Ramos To: gentoo-dev@lists.gentoo.org In-Reply-To: <1339238817.2624.15.camel@belkin4> 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> <4FD2532B.4030506@gentoo.org> <1339238817.2624.15.camel@belkin4> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9ngxf79wrqvgpwuwhmK7" Date: Sat, 09 Jun 2012 12:53:32 +0200 Message-ID: <1339239212.2624.18.camel@belkin4> 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 X-Mailer: Evolution 2.32.3 X-Archives-Salt: 4da52e16-a963-43cf-945f-c6a2882963fd X-Archives-Hash: 8ae24c98b8d079d9d3524b1d431885be --=-9ngxf79wrqvgpwuwhmK7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El s=C3=A1b, 09-06-2012 a las 12:46 +0200, Pacho Ramos escribi=C3=B3: > El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribi=C3=B3: > > 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 RDEPE= ND on > > >>>>>>>>>> glib:2.* instead. That way it would cover more cases when mo= re than > > >>>>>>>>>> two slots are available > > >>>>>>>>> > > >>>>>>>>> Well, per: > > >>>>>>>>> http://git.overlays.gentoo.org/gitweb/?p=3Dproj/pms.git;a=3Dc= ommitdiff;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 = also > > >>>>>>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this cas= e, not > > >>>>>>> sure about others I could be missing now...) > > >>>>>> > > >>>>>> The :* operator doesn't trigger any rebuilds though. Quoting the= PMS > > >>>>>> patch that you linked: > > >>>>>> > > >>>>>> * Indicates that any slot value is acceptable. In addition, for = runtime > > >>>>>> dependencies, indicates that the package will not break if the m= atched > > >>>>>> package is uninstalled and replaced by a different matching pack= age in a > > >>>>>> different slot. > > >>>>> > > >>>>> I mean, use it in conjunction with ":=3D", one for rebuild and ot= her to > > >>>>> indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to > > >>>>> periodically update RDEPENDs or need to go back from :SLOT depend= s to > > >>>>> old =3Dcategory/package-version-* ways) > > >>>>> > > >>>>> Allowing that, we wouldn't need ABI_SLOT (at least to prevent thi= s issue > > >>>>> that arises with using only SLOTs for this) > > >>>> > > >>>> What you're talking about here is more similar to ABI_SLOT operato= r deps > > >>>> than what was originally intended for SLOT operator deps. In other > > >>>> words, anyone who is opposed to ABI_SLOT operator deps is likely t= o also > > >>>> be opposed to your proposal. > > >>> > > >>> Oh :(, and what is the reason to want to prevent this behavior? Loo= ks > > >>> 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 = use > > >> ABI_SLOT because it's more flexible. > > >=20 > > > In that case, I think it's clear we need ABI_SLOT ;) The problem is h= ow > > > to document it in a way people agree with including it for eapi5 :| > >=20 > > We can just write a specification for this one feature, and ask the > > Council to approve it. >=20 > That would be nice, if you remember, I started with "elog/ecommand > splitting solution" to try to get this long standing issue solved "soon" > and, since looks like each eapi takes more than a year to complete, I > would really prefer to see it included in eapi5, specially after seeing > that this "ABI_SLOT" idea was suggested years ago but the issue stalled > later multiple times Also, taking into account that all affected packages should start migrating to eapi5 to really allow us to stop needing to use current "tricks", would be much better to start as soon as possible instead of waiting for another eapi cycle, that would delay "real solution" (I mean, new eapi used by all affected packages in the tree) even more months (or years) --=-9ngxf79wrqvgpwuwhmK7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk/TKywACgkQCaWpQKGI+9RwmQCeO5hJ0qItQqDUtTvE4Uk8gC90 yM8Anivt0wH8Xx9Wa4z5BguvttRvw2nx =6o/j -----END PGP SIGNATURE----- --=-9ngxf79wrqvgpwuwhmK7--