| 1 |
On Wed, 06 Jun 2012 11:48:26 +0200 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
> That looks nice, only two notes: |
| 4 |
> - Looks like would be more sense on distinguish between "SLOT" and |
| 5 |
> ABI_SLOT, for example: |
| 6 |
> * dbus-glib would rdepend on glib:2 |
| 7 |
> * if glib:2 abi changes, we would pull a ABI_SLOT="2.32" |
| 8 |
> inside glib-2 ebuild |
| 9 |
> * dbus-glib rdepending on glib:=2 would get rebuilt |
| 10 |
> If we would use "SLOT" for all the cases, how would we handle it? I |
| 11 |
> mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds |
| 12 |
> updated to rdepend on every new slot? Or would package managers |
| 13 |
> distinct between "versions" inside the same SLOT variable? |
| 14 |
|
| 15 |
You'd have a slot per ABI, and be encouraged to allow multiple versions |
| 16 |
of glib to be installed in parallel. If you really couldn't do that |
| 17 |
(and you should think very carefully before saying you can't, since |
| 18 |
this directly affects users in a huge way), you can make the slots |
| 19 |
block each other. |
| 20 |
|
| 21 |
> - What would occur with packages forced to use eapi0 due backwards |
| 22 |
> compat? We could probably deprecate eapis older than 5 to allow all |
| 23 |
> the tree be consistent with this rebuilds forcing, but no idea what |
| 24 |
> to do with system packages still needing to use eapi0 and maybe |
| 25 |
> changing their ABI too :/ |
| 26 |
|
| 27 |
The situation for older packages remains the same. |
| 28 |
|
| 29 |
-- |
| 30 |
Ciaran McCreesh |
Archives