Re: [gentoo-dev] EAPI-3 draft: slot operator support

[Mart Raudsepp]

On N, 2009-04-09 at 11:30 +0200, Tiziano Müller wrote:
> Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> > Hello,
> >
> >
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
> >
> > The premise is good what := and :* allow for, but I'm concerned about
> > the syntax possibly ending up being suboptimal in relation to the syntax
> > we come up in the future for covering the cases not covered now.
> >
> >
> > Such cases are for example:
> >
> > * A library package has slots 2.4, 2.6 and 2.8. An application works
> > with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> > not work with 2.4 - it has API missing that it needs.
>   DEPEND=RDEPEND=">=cat/lib-2.6:="

This is an abuse of the version number. There is no actual guarantee
that SLOT 2.6 revisions carry a 2.6* version number, etc.

> > * Same case as previous, but additionally the library has a version with
> > slot 3.0 - it is a complete redesign and applications working with 2.8
> > have no chance of working. So need to express a list of acceptable SLOTs
> > or a minimum and maximum (but slots aren't really guaranteed to be
> > numeric and versionable).
> slot operators won't help here, so it remains:
>   RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"

The package additionally needs to know which one the package manager
picked for it, to instruct the build system to actually use that
version.
Without this the whole := deal is pretty useless for many cases.

> with ranged dependencies:
>   RDEPEND="cat/lib[>=2.6&<3]:="

Version/slot mixing abuse

> or slot ranges:
>   RDEPEND="cat/lib:[2.6|2.8]="
> or
>   RDEPEND="cat/lib:=[2.6|2.8]"
> (depends on how we want to define the syntax)

I guess that would go along with the := proposed now and therefore be an
evolution and not a problem to do := now. At least for this case.

> > * Same case as previous (either of them), but if using SLOT 2.6, it
> > needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> > >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> > be necessary (considering both cases separately)
> slot operators won't help here, so it remains:
>   RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"

That doesn't work for the same reason cat/lib or || ( cat/lib:2.6
cat/lib:2.8 ) doesn't.

> again with ranged dependencies (somebody please check this):
>   RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
> or
>   RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"
>
> or maybe combined with slot ranges:
>   RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]

There is no relation between 2.8.3 and slot 2.8 here really.
We do not declare anywhere how SLOT naming related to version numbers
it's used in. So none of those examples work for me.

> please note: the ebuild maintainer has to make sure that the package has
> to use the best-matching version, otherwise even the slot specifiers are
> worthless.

The package manager needs to tell the ebuild which version it went with,
or this doesn't work right. If you assume best matching version always,
then all this slot operator deal becomes superfluous. Maintainers should
then simply always depend on just the latest version and there is
minimal benefits to slot operators and the complexity in the readability
might not be worth it.

> Real-world example for that:
> DEPEND="sys-libs/db:="
> RDEPEND="${RDEPEND}"
>
> By the time of installation you have sys-libs/db:{4.6,4.7} installed,
> then your app has to use sys-libs/db:4.7.
> (best_version should provide that information as far as I know).
>
> >
> > * A library provides slots 1.2, 1.4 and 1.6. An application can work
> > with all of them, but needs a recompile if upgrading from being linked
> > against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> > possibility of this though, involving dlopen and more. Probably
> > acceptable to declare rebuild need for all changes.
> Yes.
>
> > Are we sure := and :* is the syntax that makes sense once we try to
> > cover some of the above with new syntax?
> Yes. It's quiet extendable (as seen above).
>
> >
> > Perhaps some forward thinking is sensible here to not end up with having
> > to deprecate the := and :* syntax soon after its introduction.
> Done.


I see no need for :* based on the examples provided and can't think of
any real world cases for it either right now.
There is that theoretical case when some package does dynamic usage of
the library through dlopen and handles the ABI differences, but even
then there is no guarantee (and it is quite unlikely) that it can handle
a future ABI SLOT of the library, and so using :* is unsafe, and :=[list
of known to work ABI SLOTs] should be used instead.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@g.o
Weblog: http://planet.gentoo.org/developers/leio