-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 07/09/12 02:17 PM, Fabian Groffen wrote:
>
> No, not a GLEP, per se. I'm trying to understand what sub-slot
> does and is. I think I'm starting to understand now. However, for
> this feature to be added to an EAPI, IMO it would be nice if there
> are resources that make it for most developers very clear how this
> feature should be used (and how not), and what kind of problems it
> can solve.
>
> I guess real-life examples, more extensively described than you
> did before, with exactly where it goes wrong, and how the situation
> is improved would help.
>
I agree; I expect devmanual.gentoo.org would need a nice big page (or
section in the SLOTs page) describing it, if not at the very least a
nice entry on wiki.g.o
>>>> [1] No advantage as sub-slots wouldn't relate to this,
>>>> UNLESS the masking would then remove -all- SLOT="0/5"
>>>> versions from the tree. In that case, the old SLOT="0/3"
>>>> provider would be the 'upgrade' path and so 'foo' and 'bar'
>>>> would be triggered for rebuild (since the lib they were
>>>> linked to would be disappearing during emerge -uDN)
>>>
>>> So your example SLOTs are wrong, and should have included the
>>> minor (always!?!) since downgrading a lib that goes back to an
>>> older minor means functions no longer exist, thus a consumer
>>> can potentially break.
>>
>> If those (missing) functions are necessary then the either the
>> full slot, or the particular minimum package version, of libfnord
>> would need to be specified in the consumer. This isn't any
>> different from how things work now.
>
> Eh, no. Now it just always breaks when you perform a downgrade,
> and revdev-rebuild or @preserved-libs won't help you. I prefer
> that you give best practices how to use sub-slots to make Portage
> also able to do a recompile of bar when libfnord in the same SLOT
> gets downgraded. (Because minors are used for compatible changes --
> additions -- to the ABI.) (And the recompile is preferably done
> against the headers of the downgraded version, but with the newer
> version's lib still around, such that if this is a vital binary
> such as Python, it will not break down -- however, this is most
> likely too much to ask.)
>
I guess maybe i'm not following your example. To spell it out better,
here's what I'm understanding:
bar-1.0 has (prior to slot-operators) an RDEPEND="app-cat/libfnord".
No version specified. As such, it'll build successfully against
either libfnord-1 or libfnord-2. Right now (as i understand it) a
downgrade from libfnord-2 to libfnord-1 would "break" bar-1.0 bot
revdep-rebuild would detect and fix it.
sub-slots + slot-operators would alleviate what I just described,
auto-rebuilding bar (at least that's the theory; i've had some issues
getting portage to downgrade things even with regular slots so some
work on the implementation might be needed with this, dunno)
*IF* on the other hand, you're referring to the case of libfnord-2.1
downgrading to libfnord-2 , then yes I can see how bar-1.0 would be
broken and revdep-rebuild wouldn't fix it. However, as far as I
understand it, proper LTVERSIONing should mean that bar wouldn't break
as anything which would break bar on a libfnord-2 downgrade shouldn't
be used by bar in libfnord-2.1 -- ie, the differences would be
internal to libfnord and not directly used by bar.
If a package is -not- properly LTVERSIONed though, sub-slot bumps
could help alleviate this issue at the ebuild level.
>> This is why, for the rebuild of bar-2.4 to be triggered on
>> upgrade to libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild
>> would need to have something other than SLOT="0/5", ie,
>> SLOT="0/5.12"
>
> Yeah, but can I also avoid bar-2.4 being recompiled when I install
> libfnord-3.5? It's not necessary, because the 5-ABI of libfnord
> is supposed to be backwards compatible. (At least that's the
> idea.) Like mentioned before, I DO want bar-2.4 to be recompiled if
> I have to downgrade libfnord to a version before the one I had
> installed when I compiled bar-2.4, though.
>
Sure -- since bar-2.4 does support a codepath for <libfnord-3.5,
there's no reason to rebuild bar-2.4 to enforce it afaict.
As for the downgrade, bar-2.4 should link against libfnord.so.5.12
rather than libfnord.so.5 due to the LTVERSION-specific codepath I
think; and I also think that sub-slots couldn't be used to trigger the
rebuild on downgrade if there shouldn't be a rebuild on upgrade;
@preserve-libs would be the only way to handle this one.
>>> Do you allow sub-slot to depend on e.g. USE-flags in use?
>>> Suppose libfnord has a USE-flag cow that adds special cow
>>> interfaces to the ABI/API. Would SLOT="X/${PV}$(use cow &&
>>> echo -- -cow)" work? (I think SLOT is supposed to be
>>> metadata-static, but does the sub-slot part count to that?)
>>
>> No, afaik slots (including sub-slots) can't be dynamic. Plus we
>> already have comprehensive use deps solutions so why would we
>> need that?
>
> Because the ABI changes. But I guess you're right that we can
> safely ignore packages that screw it up badly enough here.
I think that the best way to resolve something like this would be more
comprehensive use dep usage -- ie, if bar uses the bits of libfnord
available through USE="cow" then bar is effectively dependant on those
bits and so a libfnord:=[cow?] dep (and IUSE="cow" addition if not
already there) might be appropriate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBKP2oACgkQ2ugaI38ACPA3lAD/blxSdo1onKom/rFESPbQVWU4
bXNDbxlE28YNWTjBipkBAIxacbdMUcp8t7drd+Ldh1LULp3tEPQwIhdFPtdylGi7
=0/rQ
-----END PGP SIGNATURE-----
