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