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 what would be included in EAPI5
Date: Sat, 16 Jun 2012 18:41:51 +0200
El sáb, 16-06-2012 a las 17:24 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 17:16:34 +0200
> Pacho Ramos <pacho@g.o> wrote:
> > El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > > On Sat, 16 Jun 2012 16:48:20 +0200
> > > Pacho Ramos <pacho@g.o> wrote:
> > > > Regarding the comparison with using only SLOT, the most clear
> > > > example of how that solution was a bit worse was that glib vs
> > > > dbus-glib/gobject-introspection handling:
> > > > - Using only SLOT with := would end up with we needing to update
> > > > ebuilds for packages depending on glib on each SLOT bump, that is
> > > > completely inviable.
> > > 
> > > What about if ranged dependencies existed?
> > 
> > I think this was already discussed in the same thread, but maybe we
> > are thinking in different things, could you please explain me a bit
> > more what do you mean by "ranged dependencies"? (if it would include
> > an example, even better :))
> 
> Being able to say something like >=2&<3.
> 
> > I can try to check it if no maintainer shows more packages
> > showing this stable API unstable ABIs issues
> 
> Please do. This is a fairly important point: if the number of affected
> packages is small, there's no point in introducing sub-slots.
> 

Simply grepping for qfile usages, I see similar problems for gtk
+/gdk-pixbuf and any package providing /usr/lib/gtk-2.0/2.* files.

Also similar problem with PyQt4 packages, and sip ones. And this is not
counting packages that tell people to manually run "emerge 'some
package'" directly

> > > You're misunderstanding the point of the * there. The * has nothing
> > > to do with wildcarding.
> > 
> > Probably, what is "*" sense in this context? I was thinking more on a
> > bash context when I would use "*" to fit any 2.x case
> 
> It means "and the slot can be switched at runtime, without causing
> breakage". Thus it's only meaningful on dependencies that are both
> build- and run-.
> 
> The :*/:= feature was designed to solve one specific problem: if a user
> has foo installed, and foo deps upon bar, and bar:1 is installed, and
> the user wants to install bar:2 and then uninstall bar:1, will foo
> break? :* means no, := means yes.
> 

And, wouldn't it be covered simply making that package not depend on any
slot specifically?

> > Also, maybe you could talk with other exherbo maintainers as I am sure
> > they have also experienced this kind of problem (packages needing to
> > be rebuilt after update of other one), maybe they could join forces
> > with us to try to reach an exact description of the problem and a
> > solution :/
> 
> I'm pretty sure the route Exherbo is going to take with this is very
> different, and will involve souped-up USE flags that allow "parts" of a
> package (such as its libraries) to be kept around, possibly together
> with a special form of blocker that acts only upon installed packages,
> with a strict post ordering. It's not going to involve sub-slots, in
> any case.
> 

Well, probably the problem is to predict when will that be really solved
there :(
Attachment:
signature.asc (This is a digitally signed message part)
Replies:
Re: About what would be included in EAPI5
-- Ciaran McCreesh
References:
About what would be included in EAPI5
-- Pacho Ramos
Re: About what would be included in EAPI5
-- Ulrich Mueller
Re: About what would be included in EAPI5
-- Pacho Ramos
Re: About what would be included in EAPI5
-- Ciaran McCreesh
Re: About what would be included in EAPI5
-- Pacho Ramos
Re: About what would be included in EAPI5
-- Ciaran McCreesh
Re: About what would be included in EAPI5
-- Pacho Ramos
Re: About what would be included in EAPI5
-- Ciaran McCreesh
Re: About what would be included in EAPI5
-- Pacho Ramos
Re: About what would be included in EAPI5
-- Pacho Ramos
Re: About what would be included in EAPI5
-- Ciaran McCreesh
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: About what would be included in EAPI5
Next by thread:
Re: About what would be included in EAPI5
Previous by date:
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Next by date:
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual


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.