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