1 |
El sáb, 09-06-2012 a las 12:46 +0200, Pacho Ramos escribió: |
2 |
> El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió: |
3 |
> > On 06/08/2012 12:23 PM, Pacho Ramos wrote: |
4 |
> > > El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: |
5 |
> > >> On 06/08/2012 01:38 AM, Pacho Ramos wrote: |
6 |
> > >>> El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: |
7 |
> > >>>> On 06/07/2012 12:24 PM, Pacho Ramos wrote: |
8 |
> > >>>>> El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: |
9 |
> > >>>>>> On 06/07/2012 12:00 PM, Pacho Ramos wrote: |
10 |
> > >>>>>>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: |
11 |
> > >>>>>>>> On Thu, 07 Jun 2012 20:43:54 +0200 |
12 |
> > >>>>>>>> Pacho Ramos <pacho@g.o> wrote: |
13 |
> > >>>>>>>>>> I would prefer, as a workaround, allow reverse deps to RDEPEND on |
14 |
> > >>>>>>>>>> glib:2.* instead. That way it would cover more cases when more than |
15 |
> > >>>>>>>>>> two slots are available |
16 |
> > >>>>>>>>> |
17 |
> > >>>>>>>>> Well, per: |
18 |
> > >>>>>>>>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b |
19 |
> > >>>>>>>>> |
20 |
> > >>>>>>>>> looks like "*" usage for SLOTs would be allowed :), or I am |
21 |
> > >>>>>>>>> misinterpreting it? |
22 |
> > >>>>>>>> |
23 |
> > >>>>>>>> It's not a wildcard. |
24 |
> > >>>>>>>> |
25 |
> > >>>>>>> |
26 |
> > >>>>>>> But it looks like a valid usage for cases like glib vs. |
27 |
> > >>>>>>> dbus-glib/gobject-introspection I have exposed as example, and also |
28 |
> > >>>>>>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not |
29 |
> > >>>>>>> sure about others I could be missing now...) |
30 |
> > >>>>>> |
31 |
> > >>>>>> The :* operator doesn't trigger any rebuilds though. Quoting the PMS |
32 |
> > >>>>>> patch that you linked: |
33 |
> > >>>>>> |
34 |
> > >>>>>> * Indicates that any slot value is acceptable. In addition, for runtime |
35 |
> > >>>>>> dependencies, indicates that the package will not break if the matched |
36 |
> > >>>>>> package is uninstalled and replaced by a different matching package in a |
37 |
> > >>>>>> different slot. |
38 |
> > >>>>> |
39 |
> > >>>>> I mean, use it in conjunction with ":=", one for rebuild and other to |
40 |
> > >>>>> indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to |
41 |
> > >>>>> periodically update RDEPENDs or need to go back from :SLOT depends to |
42 |
> > >>>>> old =category/package-version-* ways) |
43 |
> > >>>>> |
44 |
> > >>>>> Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue |
45 |
> > >>>>> that arises with using only SLOTs for this) |
46 |
> > >>>> |
47 |
> > >>>> What you're talking about here is more similar to ABI_SLOT operator deps |
48 |
> > >>>> than what was originally intended for SLOT operator deps. In other |
49 |
> > >>>> words, anyone who is opposed to ABI_SLOT operator deps is likely to also |
50 |
> > >>>> be opposed to your proposal. |
51 |
> > >>> |
52 |
> > >>> Oh :(, and what is the reason to want to prevent this behavior? Looks |
53 |
> > >>> much simpler to me than needing to use ranges for dependencies or |
54 |
> > >>> needing to create "compat" packages to hide the problem :| |
55 |
> > >> |
56 |
> > >> It's close enough to ABI_SLOT that it would make more sense just to use |
57 |
> > >> ABI_SLOT because it's more flexible. |
58 |
> > > |
59 |
> > > In that case, I think it's clear we need ABI_SLOT ;) The problem is how |
60 |
> > > to document it in a way people agree with including it for eapi5 :| |
61 |
> > |
62 |
> > We can just write a specification for this one feature, and ask the |
63 |
> > Council to approve it. |
64 |
> |
65 |
> That would be nice, if you remember, I started with "elog/ecommand |
66 |
> splitting solution" to try to get this long standing issue solved "soon" |
67 |
> and, since looks like each eapi takes more than a year to complete, I |
68 |
> would really prefer to see it included in eapi5, specially after seeing |
69 |
> that this "ABI_SLOT" idea was suggested years ago but the issue stalled |
70 |
> later multiple times |
71 |
|
72 |
Also, taking into account that all affected packages should start |
73 |
migrating to eapi5 to really allow us to stop needing to use current |
74 |
"tricks", would be much better to start as soon as possible instead of |
75 |
waiting for another eapi cycle, that would delay "real solution" (I |
76 |
mean, new eapi used by all affected packages in the tree) even more |
77 |
months (or years) |