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 <pa...@gentoo.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 <pa...@gentoo.org> 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 :(
signature.asc
Description: This is a digitally signed message part
