1 |
El sáb, 16-06-2012 a las 17:16 +0200, Pacho Ramos escribió: |
2 |
> El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió: |
3 |
> > On Sat, 16 Jun 2012 16:48:20 +0200 |
4 |
> > Pacho Ramos <pacho@g.o> wrote: |
5 |
> > > Regarding the comparison with using only SLOT, the most clear example |
6 |
> > > of how that solution was a bit worse was that glib vs |
7 |
> > > dbus-glib/gobject-introspection handling: |
8 |
> > > - Using only SLOT with := would end up with we needing to update |
9 |
> > > ebuilds for packages depending on glib on each SLOT bump, that is |
10 |
> > > completely inviable. |
11 |
> > |
12 |
> > What about if ranged dependencies existed? |
13 |
> |
14 |
> I think this was already discussed in the same thread, but maybe we are |
15 |
> thinking in different things, could you please explain me a bit more |
16 |
> what do you mean by "ranged dependencies"? (if it would include an |
17 |
> example, even better :)) |
18 |
> |
19 |
> > |
20 |
> > Also, we've yet to establish whether SLOT-with-/ really solves this |
21 |
> > problem, nor whether the problem is a general one. How many packages |
22 |
> > are there with stable APIs but unstable ABIs? |
23 |
> > |
24 |
> |
25 |
> Good point, if other maintainers don't talk about their packages (as |
26 |
> they will for sure know why they need rebuilding exactly), would need to |
27 |
> grep in the tree looking for rebuild instructions for figure out :/, I |
28 |
> can try to check it if no maintainer shows more packages showing this |
29 |
> stable API unstable ABIs issues |
30 |
> |
31 |
|
32 |
Also, maybe you could talk with other exherbo maintainers as I am sure |
33 |
they have also experienced this kind of problem (packages needing to be |
34 |
rebuilt after update of other one), maybe they could join forces with us |
35 |
to try to reach an exact description of the problem and a solution :/ |
36 |
|
37 |
> > > - I suggested then to be able to make that packages depend on :* (for |
38 |
> > > example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to |
39 |
> > > get their ebuilds updated as they would still fit inside "2.*" case, |
40 |
> > > but would still get rebuild (as wanted) due := usage... but you also |
41 |
> > > didn't like this approach. |
42 |
> > |
43 |
> > You're misunderstanding the point of the * there. The * has nothing to |
44 |
> > do with wildcarding. |
45 |
> |
46 |
> Probably, what is "*" sense in this context? I was thinking more on a |
47 |
> bash context when I would use "*" to fit any 2.x case |
48 |
> |
49 |
> > |
50 |
> > > > > About what I am trying to solve, I have explained it multiple |
51 |
> > > > > times in involved thread and won't repeat them once again. |
52 |
> > > > |
53 |
> > > > Describing the problem clearly and correctly, and in the appropriate |
54 |
> > > > amount of generality, is the hardest and most important part of the |
55 |
> > > > process. Figuring out what we're trying to solve is far harder than |
56 |
> > > > writing a bit of code. |
57 |
> > > |
58 |
> > > What I try to do is to replace the needing of manually rebuilding |
59 |
> > > packages after updates due ABI changes, like currently occurs with |
60 |
> > > xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like |
61 |
> > > that. |
62 |
> > |
63 |
> > See, that's not really a description of the problem. It's a good start, |
64 |
> > but I'd expect a full description to run to be several pages of |
65 |
> > detailed description of the general case, along with worked out |
66 |
> > examples. This isn't an easy issue, and we don't want to come up with a |
67 |
> > solution that works for one particular package whilst ignoring the |
68 |
> > needs of everything else. |
69 |
> > |
70 |
> > > Regarding other problems like needing to use perl-cleaner, |
71 |
> > > python-updater looks to be covered by another approach of "dynamic |
72 |
> > > slots" I have just seen in gentoo-dev IRC channel by mgorny, then, |
73 |
> > > that kind of issues would be uncovered with this (but maybe I am |
74 |
> > > wrong as I know Zac had a more clear conception about how this |
75 |
> > > ABI_SLOT way would work and what would it cover) |
76 |
> > |
77 |
> > Somehow I don't think this cunning plan has been thought all the way |
78 |
> > through... |
79 |
> > |
80 |
> > Coming up with a "solution" rather than a description of the problem is |
81 |
> > the wrong thing to do. |
82 |
> > |
83 |
> |
84 |
> |