Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue
Date: Fri, 08 Jun 2012 19:17:29
In Reply to: Re: [gentoo-dev] About forcing rebuilds of other packages issue by Pacho Ramos
On 06/08/2012 01:38 AM, Pacho Ramos wrote:
> El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: >> On 06/07/2012 12:24 PM, Pacho Ramos wrote: >>> El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: >>>> On 06/07/2012 12:00 PM, Pacho Ramos wrote: >>>>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: >>>>>> On Thu, 07 Jun 2012 20:43:54 +0200 >>>>>> Pacho Ramos <pacho@g.o> 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: >>>>>>>;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b >>>>>>> >>>>>>> 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 case, 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 matched >>>> package is uninstalled and replaced by a different matching package in a >>>> different slot. >>> >>> I mean, use it in conjunction with ":=", one for rebuild and other 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 =category/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 use ABI_SLOT because it's more flexible. -- Thanks, Zac