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

[Ciaran McCreesh]

On Thu, 09 Apr 2009 04:51:06 +0300
Mart Raudsepp <leio@g.o> wrote:
> doins support for symlinks
> ==========================
>
> Lacking information. Need to see if the PMS draft has anything about
> it. The bug and summaries just talk about the support, but no
> details. Would it be an argument to doins?

The PMS draft explains it. It's simple, though: currently, doins on a
symlink does something arbitrary. We want it to install the symlink.

> unpack failing on unknown types
> ===============================
>
> Uncertain about it's worthiness. Might rather have the opposite with a
> --strict argument kind of deal. No official objection from me.

What with the moving towards auto-die, the trend is towards "strict
unless explicitly told not to be".

> properties must be cached properly
> ==================================
>
> No opinion, up to the package manager developers.
> Don't see offhand why it should be an EAPI item at all. Feels like an
> implementation detail.

The cache format's tied to EAPI in a fairly unpleasant manner. It's a
necessary evil.

> DEFINED_PHASES must be supported (and cached properly)
> ======================================================
>
> No opinion, up to the package manager developers more or less.
> Not sure why this needs to be an EAPI item. Hard to see a use case for
> the variable being available for ebuild usage for it to be necessary
> to be an EAPI item.

DEFINED_PHASES isn't available to the ebuild. But it is in the metadata
cache, which PMS has to cover.

> By my understanding it is (also?) a required implementation detail to
> handle pkg_pretend sanely and with minimal time hit.

Correct. Without it there's a delay of ~0.1s per ebuild in the
resolution set at pretend time, which soon adds up for certain
reasonably common use cases.

> Limit values in $USE to ones in $IUSE:
> ======================================
>
> Seems more of a QA test, but forcing it can make it be caught at
> start. Don't see why it must be an EAPI item. Just vet the tree of
> (future?) repoman warnings about it and make it happen for
> all EAPIs. Impact on overlays is minimal because it is a QA error to
> not define them and they get what they asked for.

It needs to be in EAPI because we're talking about changing how the
ebuild environment is specified. Also, repoman can't catch most
accidental abuses of this.

> --disable-dependency-tracking:
> ==============================
>
> possible breakage of (custom) configure scripts that don't accept
> unknown arguments. Would be nice to pass that for most packages, but
> doing it always with econf seems slightly inappropriate, given the
> above.

Please provide a list of packages that use custom configure scripts,
that currently work with econf (including all the weird things it
already passes), that would break with this change and whose ebuilds are
using econf. I have yet to see any examples provided.

> utility commands should die by default
> ======================================
>
> Would like to see a list of those utility commands that would be made
> to die by default.

The PMS draft has one.

> ban || ( foo? ( . ) . )
> =======================
>
> It is not the business of an EAPI to start disallowing *DEPEND string
> constructs.
> There is no useful alternative provided yet to my knowledge and this
> is really a QA issue, not an EAPI issue.

There is no use case for the construct anyway.

> Not convinced on the sub-optimal use case being the only one, either.
>
> Strongly objecting on the grounds that it is not something that should
> be an EAPI issue.

Behaviour of || ( foo? ( . ) ) is already an EAPI issue, and has a
horrible section of PMS devoted to explaining its quirky behaviour.

> I'm not even sure anymore where to find a list of items that is
> current for what's on the table for EAPI-3 right now...

Do a git log on the PMS draft (or look at the summary table in the
appendix). It's fairly close to one commit per EAPI item.

-- 
Ciaran McCreesh