| 1 |
On 09/06/2012 02:01 AM, Fabian Groffen wrote: |
| 2 |
> After reading this thread, I have seen numerous occasions where has been |
| 3 |
> asked what this proposal actually solves. Unless I've accidentially |
| 4 |
> skipped over it, the answer has yet to be given. It appears to me now |
| 5 |
> sub-slot is a feature that makes it easy to express a situation that |
| 6 |
> could be expressed today as well, but requiring more work. As such |
| 7 |
> "syntactic sugar", it seems not well bounded, allowing possibly for |
| 8 |
> doing things that result in a big mess (I cannot prove this atm, and |
| 9 |
> there is no specification afaict.) |
| 10 |
|
| 11 |
The sub-slot is needed for those cases where it's just not practical to |
| 12 |
bump the regular slot. Tiziano Müller (dev-zero) has summarized the |
| 13 |
possible solutions well [1]: |
| 14 |
|
| 15 |
> I see four possibilities: |
| 16 |
> 1) patch them to version the headers as well and slot them (together with slot operator deps) |
| 17 |
> 2) ask upstream to properly version the headers alongside with the lib and slot them (together with slot operator deps) |
| 18 |
> 3) slot them and block old slots in newer versions (together with slot operator deps) |
| 19 |
> 4) introduce a new EAPI variable which can be incremented whenever an soname changes (needs some more thinking and proper specification, somehow duplicates SLOT) |
| 20 |
|
| 21 |
Sub-slot implements #4 (by extending the SLOT variable instead of using |
| 22 |
a new variable). |
| 23 |
|
| 24 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=414955#c10 |
| 25 |
-- |
| 26 |
Thanks, |
| 27 |
Zac |
Archives