Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

On Sun, 08 Mar 2009 00:08:37 -0800
Josh Saddler <nightmo...@gentoo.org> wrote:
> Is there a reason why we should ram through a new EAPI for something
> that *looks* like another "Paludis supports this so let's make it a
> Portage standard" proposal? Is there some kind of time deadline here
> that you all want?

If we were sticking through "things Paludis has that're useful", the
list would be an awful lot longer... And not everything on that list is
even in Paludis... But hey, some things never go out of fashion.

A few things on the list are required pretty soon. Bug 249166 and
various existing screwups in the tree suggest that [use(+)] (or
whatever syntax is decided upon) is going to crop up fairly frequently.
And certain people are reluctant to nuke their prepalldocs calls
despite Council decisions... I think the rest are just there because
they're useful and easy.

> Also, why the bannination of || ( foo? (.).) -- how is it error prone,
> exactly.

Last time I checked, every single use of foo? as a direct child of ||
in the tree was wrong, as were the Portage docs. Let's say you have the
following:

    DEPEND="|| (
        foo? ( cat/foo )
        bar? ( cat/bar )
        cat/baz
    )"

Then this is wrong:

    if use foo ; then
        myconf="--enable-foo"
    elif use bar ; then
        myconf="--enable-bar"
    else
        myconf="--enable-baz
    fi

Here's why:

Say the user already has baz installed, and has USE="foo". The package
manager will see that baz is already installed, and as per the rules
for || will not look at the foo or bar deps. So if the user doesn't
have foo installed, the --enable-foo will be wrong.

So the 'correct' code would have to be something like this:

    if use foo && has_version cat/foo ; then
        myconf="--enable-foo"
    elif use bar && has_version cat/bar ; then
        myconf="--enable-bar"
    else
        myconf="--enable-baz
    fi

Except this is *still* a mess, because a user who has USE="foo bar" is
going to end up with a differently configured package depending upon
what he happens to have installed up-front, which is something that's
not supposed to happen.

-- 
Ciaran McCreesh

signature.asc
Description: PGP signature