On Sat, 16 Jun 2012 17:16:34 +0200
Pacho Ramos <firstname.lastname@example.org> 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 <email@example.com> 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.
> > 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.
> 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