1 |
El sáb, 16-06-2012 a las 17:24 +0100, Ciaran McCreesh escribió: |
2 |
> On Sat, 16 Jun 2012 17:16:34 +0200 |
3 |
> Pacho Ramos <pacho@g.o> wrote: |
4 |
> > El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió: |
5 |
> > > On Sat, 16 Jun 2012 16:48:20 +0200 |
6 |
> > > Pacho Ramos <pacho@g.o> wrote: |
7 |
> > > > Regarding the comparison with using only SLOT, the most clear |
8 |
> > > > example of how that solution was a bit worse was that glib vs |
9 |
> > > > dbus-glib/gobject-introspection handling: |
10 |
> > > > - Using only SLOT with := would end up with we needing to update |
11 |
> > > > ebuilds for packages depending on glib on each SLOT bump, that is |
12 |
> > > > completely inviable. |
13 |
> > > |
14 |
> > > What about if ranged dependencies existed? |
15 |
> > |
16 |
> > I think this was already discussed in the same thread, but maybe we |
17 |
> > are thinking in different things, could you please explain me a bit |
18 |
> > more what do you mean by "ranged dependencies"? (if it would include |
19 |
> > an example, even better :)) |
20 |
> |
21 |
> Being able to say something like >=2&<3. |
22 |
> |
23 |
> > I can try to check it if no maintainer shows more packages |
24 |
> > showing this stable API unstable ABIs issues |
25 |
> |
26 |
> Please do. This is a fairly important point: if the number of affected |
27 |
> packages is small, there's no point in introducing sub-slots. |
28 |
> |
29 |
|
30 |
Simply grepping for qfile usages, I see similar problems for gtk |
31 |
+/gdk-pixbuf and any package providing /usr/lib/gtk-2.0/2.* files. |
32 |
|
33 |
Also similar problem with PyQt4 packages, and sip ones. And this is not |
34 |
counting packages that tell people to manually run "emerge 'some |
35 |
package'" directly |
36 |
|
37 |
> > > You're misunderstanding the point of the * there. The * has nothing |
38 |
> > > to do with wildcarding. |
39 |
> > |
40 |
> > Probably, what is "*" sense in this context? I was thinking more on a |
41 |
> > bash context when I would use "*" to fit any 2.x case |
42 |
> |
43 |
> It means "and the slot can be switched at runtime, without causing |
44 |
> breakage". Thus it's only meaningful on dependencies that are both |
45 |
> build- and run-. |
46 |
> |
47 |
> The :*/:= feature was designed to solve one specific problem: if a user |
48 |
> has foo installed, and foo deps upon bar, and bar:1 is installed, and |
49 |
> the user wants to install bar:2 and then uninstall bar:1, will foo |
50 |
> break? :* means no, := means yes. |
51 |
> |
52 |
|
53 |
And, wouldn't it be covered simply making that package not depend on any |
54 |
slot specifically? |
55 |
|
56 |
> > Also, maybe you could talk with other exherbo maintainers as I am sure |
57 |
> > they have also experienced this kind of problem (packages needing to |
58 |
> > be rebuilt after update of other one), maybe they could join forces |
59 |
> > with us to try to reach an exact description of the problem and a |
60 |
> > solution :/ |
61 |
> |
62 |
> I'm pretty sure the route Exherbo is going to take with this is very |
63 |
> different, and will involve souped-up USE flags that allow "parts" of a |
64 |
> package (such as its libraries) to be kept around, possibly together |
65 |
> with a special form of blocker that acts only upon installed packages, |
66 |
> with a strict post ordering. It's not going to involve sub-slots, in |
67 |
> any case. |
68 |
> |
69 |
|
70 |
Well, probably the problem is to predict when will that be really solved |
71 |
there :( |