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.)
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.
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.
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.
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.
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.
Please enlighten me.
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
