Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Pacho Ramos <pacho@g.o>
Subject: Re: About forcing rebuilds of other packages issue
Date: Sat, 09 Jun 2012 12:53:32 +0200
El sáb, 09-06-2012 a las 12:46 +0200, Pacho Ramos escribió:
> El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió:
> > On 06/08/2012 12:23 PM, Pacho Ramos wrote:
> > > El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió:
> > >> 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:
> > >>>>>>>>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;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.
> > > 
> > > 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.
> 
> 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)
Attachment:
signature.asc (This is a digitally signed message part)
References:
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Brian Harring
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: About forcing rebuilds of other packages issue
Next by thread:
Re: About forcing rebuilds of other packages issue
Previous by date:
Fwd: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
Next by date:
Re: About forcing rebuilds of other packages issue


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.