-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 06/09/12 05:01 AM, Fabian Groffen wrote:
> Replying to this email since it seems to be the discussion behind
> the "sub-slot" feature proposed for EAPI 5.
>
> On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
>> This is why I think we should try to push a bit my first
>> suggestion for the short term until "the perfect one" is ready
>> as, until then, we are having for years a problem that,
>> personally, I think it should be handled a bit better.
>
> 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.)
>
#1 - there is both a specification, and an initial implementation, AND
a fork of the tree that is kept semi-up-to-date on my dev overlay. So
please test away. At present sub-slots have been set on Xorg
(automatically rebuilding x11-drivers/* on upgrades), and on perl
(automatically rebuilding everything (afaik) that perl-cleaner would
normally be needed for). There should be more than enough work done
on my portage fork for you to be able to experiment and prove/disprove
said mess.
#2 - related to your question about what the proposal solves -- in my
opinion, the biggest thing the proposal solves is the case where we
want the ability to use SLOTs in the tree to manage and track
dependency changes (ie, when an API or ABI has changed), but NOT allow
multiple versions of a package to be installed at the same time.
Further to this, it allows PMs to determine what needs to be rebuilt
due to the old (no longer existing) dep being supported prior to said
dep actually being removed.
> So, I'm looking for a specification what the components in the
> sub-slot exactly mean, and what behaviour they trigger. To me, it
> seems right now that sub-slot is simply ${SLOT}/${PV}, and some
> fancy sub-part matching (up to the '/' actually). It would be nice
> to have a sound and clear definition of that the SLOT value means,
> and what the sub-slot value means. How can one make it up? Could
> one also just start with 1 as sub-slot? Or use names?
> (SLOT="2/$(use fnord && echo fnord)"). I have no clue how to use
> this correctly, as well as what problems I should have that it
> solves.
sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
It doesn't have to replate to ${PV} at all, and generally shouldn't.
More likely it should relate to the ${major}.${minor} in the main
library's SONAME. For non-libtool dependencies some other form of id
is used, ie for perl I used the major.minor from $PV.
>
> To clarify the last bit, could you please explain how the
> following situation benefits from sub-slot.
>
> Consider the packages libfnord, foo and bar. libfnord being a
> library, used by foo and bar, which are simple executables.
> libfnord has 6 versions (not necessarily all at the same time in
> the tree), with ELF soname and library versions:
>
> libfnord-1 libfnord.so.3 libfnord.so.3.0 libfnord-2
> libfnord.so.5 libfnord.so.5.1 libfnord-2.1 libfnord.so.5
> libfnord.so.5.2 libfnord-2.1-r5 libfnord.so.5
> libfnord.so.5.2 libfnord-3 libfnord.so.5
> libfnord.so.5.8 libfnord-3.5 libfnord.so.5
> libfnord.so.5.12
>
> Package foo and bar have the following versions and {,R}DEPEND:
>
> foo-3.0 >=libfnord-2 bar-1.234b =libfnord-1*
> bar-2.4 >=libfnord-3
>
> How would the SLOT and {,R}DEPEND values for these ebuilds look
> like, what happens when libfnord 2 and 3 are introduced in the
> tree, etc. Please show for both EAPI 4, EAPI 4+slot-deps and EAPI
> 4+sub-slot.
EAPI="4-slot-deps" is new to me; the implementation i've been testing
is EAPI="4-slot-abi" which is sub-slots and slot operators. This is
the spec that was written and proposed for EAPI=5 and so this is what
i'll use to describe the above.
First, assuming currently libfnord is SLOT=0, and that there are no
ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
the ${major} version from the SONAME for the sub-slot. IE:
libfnord-1:SLOT="0/3"
libfnord-2:SLOT="0/5"
libfnord-2.1:SLOT="0/5"
...
libfnord-3.5:SLOT="0/5"
And then, assuming that foo and bar both link in the usual way, IE
they link against libfnord.so.3 instead of just libfnord.so , they
both would RDEPEND as follows:
RDEPEND="app-cat/libfnord:="
> (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> would be masked due to some problem not noticed prior to stabling
> that makes it useless for many users. [2]bar-2.4 during configure
> checks for a new function in libfnord-3.5 and uses it if available,
> or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes
> a crash in some function of the library. (Note: this whole
> example/question sounds like an ebuild-quiz question that any dev
> should be able to answer then.)
>
> What would be the advantage of sub-slot here, assuming the
> versioning of the libraries follows ABI versioning rules defined by
> e.g. libtool.
[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)
[2] In this case, the new ABI/API offering in libfnord-3.5 would need
to be addressed in the SLOT, ie, SLOT="0/5.12". As such when
libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged
of course) would be triggered for rebuild. 'foo' would afaik also be
triggered for rebuild, though, as (at present) there isn't a way to
match partial sub-slots (or sub-sub-slots, as it were) via the slot
operators := and :*.
[3] No advantage, as linking would be consistent. Sub-slots wouldn't
be needed in this case, and afaict updating libfnord-2.1 to
libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any
additional mediation anyways.
Hope this helps clear things up..
Ian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBIpGEACgkQ2ugaI38ACPBAAAD/T7kE+KkCJ2IfeHOmP/WYb+CX
ofEfsqWXZ2L0aNWDoZIA/0MeHvdH3Yul/SayBbg1Z1Etmiv6vt7f2QqBPArAl/L8
=pLhN
-----END PGP SIGNATURE-----
