| 1 |
On 06/06/2012 10:16 AM, Ciaran McCreesh wrote: |
| 2 |
> On Wed, 06 Jun 2012 11:48:26 +0200 |
| 3 |
> Pacho Ramos <pacho@g.o> wrote: |
| 4 |
>> That looks nice, only two notes: |
| 5 |
>> - Looks like would be more sense on distinguish between "SLOT" and |
| 6 |
>> ABI_SLOT, for example: |
| 7 |
>> * dbus-glib would rdepend on glib:2 |
| 8 |
>> * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" |
| 9 |
>> inside glib-2 ebuild |
| 10 |
>> * dbus-glib rdepending on glib:=2 would get rebuilt |
| 11 |
>> If we would use "SLOT" for all the cases, how would we handle it? I |
| 12 |
>> mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds |
| 13 |
>> updated to rdepend on every new slot? Or would package managers |
| 14 |
>> distinct between "versions" inside the same SLOT variable? |
| 15 |
> |
| 16 |
> You'd have a slot per ABI, and be encouraged to allow multiple versions |
| 17 |
> of glib to be installed in parallel. If you really couldn't do that |
| 18 |
> (and you should think very carefully before saying you can't, since |
| 19 |
> this directly affects users in a huge way), you can make the slots |
| 20 |
> block each other. |
| 21 |
|
| 22 |
It seems like you're trying to make glib fit your SLOT operator model, |
| 23 |
even though it's a natural fit for the ABI_SLOT operator model. |
| 24 |
-- |
| 25 |
Thanks, |
| 26 |
Zac |
Archives