| 1 |
El jue, 07-06-2012 a las 11:03 -0700, Zac Medico escribió: |
| 2 |
> On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: |
| 3 |
> > On Thu, 07 Jun 2012 09:43:32 -0700 |
| 4 |
> > Zac Medico <zmedico@g.o> wrote: |
| 5 |
> >> I can imagine that ABI_SLOT operator deps will be a lot more popular |
| 6 |
> >> than SLOT operator deps, since ABI_SLOT operator deps will accommodate |
| 7 |
> >> the common practice of allowing ABI changes within a particular SLOT. |
| 8 |
> > |
| 9 |
> > You're missing out on a brilliant opportunity to encourage developers |
| 10 |
> > put in a bit more work to save users a huge amount of pain here. |
| 11 |
> |
| 12 |
> What about cases like the dbus-glib and glib:2 dependency, where it's |
| 13 |
> just too much trouble to use SLOT operator deps? Wouldn't it be better |
| 14 |
> to have a little flexibility, so that we can accommodate more packages? |
| 15 |
> |
| 16 |
> As a workaround for SLOT operator deps, I suppose that glib:1 could be |
| 17 |
> split into a separate glib-legacy package, in order to facilitate the |
| 18 |
> use of SLOT operator dependencies in dbus-glib. That way, it would be |
| 19 |
> easy to match glib-2.x and not have to worry about trying not to match |
| 20 |
> glib-1.x. |
| 21 |
|
| 22 |
I would prefer, as a workaround, allow reverse deps to RDEPEND on |
| 23 |
glib:2.* instead. That way it would cover more cases when more than two |
| 24 |
slots are available |
Archives