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: Wed, 06 Jun 2012 20:02:24 +0200
El mié, 06-06-2012 a las 18:16 +0100, Ciaran McCreesh escribió:
> On Wed, 06 Jun 2012 11:48:26 +0200
> Pacho Ramos <pacho@g.o> wrote:
> > That looks nice, only two notes:
> > - Looks like would be more sense on distinguish between "SLOT" and
> > ABI_SLOT, for example:
> > 	* dbus-glib would rdepend on glib:2
> > 	* if glib:2 abi changes, we would pull a ABI_SLOT="2.32"
> > inside glib-2 ebuild
> > 	* dbus-glib rdepending on glib:=2 would get rebuilt
> > If we would use "SLOT" for all the cases, how would we handle it? I
> > mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds
> > updated to rdepend on every new slot? Or would package managers
> > distinct between "versions" inside the same SLOT variable?
> 
> You'd have a slot per ABI, and be encouraged to allow multiple versions
> of glib to be installed in parallel. If you really couldn't do that
> (and you should think very carefully before saying you can't, since
> this directly affects users in a huge way), you can make the slots
> block each other.

Probably other gnome team could reply this better than me, but I don't
think slotting every glib-2 due ABI changes deserves the huge effort.
Also, we want people to rebuild them against, for example, glib-2.32
ABI, not to keep glib-2.30 and 2.32 installed in parallel and some
packages built against 2.30 and others against 2.32.

Also, how could this be handled in dbus-glib side? I mean, would we need
to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O

> 
> > - What would occur with packages forced to use eapi0 due backwards
> > compat? We could probably deprecate eapis older than 5 to allow all
> > the tree be consistent with this rebuilds forcing, but no idea what
> > to do with system packages still needing to use eapi0 and maybe
> > changing their ABI too :/
> 
> The situation for older packages remains the same.
> 

Maybe we have a third option that could allow us to not use ABI_SLOT if
you prefer:
- eapi5 could allow the usage of depending on multiple slots, for
example, dbus-glib would RDEPEND on dev-libs/glib:2.*:=
Then, we would have dev-libs/glib:2.30 and dev-libs/glib:2.32, both
mutually exclusive but ebuilds RDEPENDing on them not needing to be
updated on every abi bump due them really working for both ABIs.
- Package managers would still rebuild all apps with that ":=" syntax
- We would be able to skip ABI_SLOT needing
- If a package is RDEPENDing on an old eapi0 package, that package could
still use SLOT="2.32" or "2.30" and eapi5 ebuild rdepending on it still
behaving in the same way.


Attachment:
signature.asc (This is a digitally signed message part)
Replies:
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
References:
[gentoo-portage-dev] About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: [gentoo-portage-dev] About forcing rebuilds of other packages issue
-- Aaron W. Swenson
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
-- Ciaran McCreesh
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:
Re: Lastrite: net-libs/xulrunner
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.