[gentoo-project] EAPI6 Features

[Rich Freeman]

Most of the proposed EAPI6 features seem ripe for acceptance, but I
figured I'd comment on a few here in case others want to weigh in.

On Thu, May 29, 2014 at 9:56 AM, Ulrich Mueller <ulm@g.o> wrote:
>
>    b) failglob in global scope
>         Bug #463822 [13]

I'm a bit concerned that this one could be a cure worse than the
disease - unintended side-effects/etc.  A repoman check seems a lot
less likely to cause problems.

Part of me wonders that there is a trend towards using bash as a
general-purpose programming language.  Just about any higher-level
data/control/etc structure in bash tends to be cumbersome.  Really all
the non-fatal die stuff is nothing more than exception handling in a
language not designed for exception handling, but that at least seems
manageable.

>
> 4. Features rejected from EAPI 5

Ok, I suspect we're going to spend about 95% of the time on these.
Few have much progress since the last time they were rejected.

>
>    a) Patch applying function in package manager
>         Bug #463768 [14]
>         - Needed for 2d) and 4b)
>         - This will duplicate epatch() from eutils, in simplified form.
>         - Name "eapply" has been suggested.
>

My two cents.  Keep an eclass for the fancy stuff, but move into the
EAPI a few basic patch functions:

1.  Application of a patch file, defaulting to -p1, allowing override
of -p level, but without auto-detection.
2.  Application of a directory full of patch files in lexical order,
again supporting override of -p level without auto-detection.

I'm not a big fan of either auto-detection or forcing patch re-writes
to be -p1 always.

>    b) User patches
>         Bug #475288 [15], PMS wording [16]
>         - Needs 4a)
>         - Current wording of the spec requires that every ebuild must
>           include a call to the function in src_prepare, which is
>           controversial.
>         - Names "apply_user_patches" or "eapply_user" have been suggested.
>

I'm generally fine with it (we can bikeshed the name to death later),
but is there any reason to not just simply apply the patches after
src_prepare is done and not make maintainers call it?  If we're
concerned about sequencing with other activities in src_prepare then
that is fine - I don't have a big problem with it being a fatal error
if it doesn't get called.

>    c) EJOBS variable
>         Bug #273101 [17], gentoo-dev discussion [18]
>         - Discussion was in 2008. Is there (still) consensus?
>

Assuming anybody still wants to implement this, I see no reason to
keep bikeshedding this.  EJOBS fits the bill.

The only thing that might be worth noting is that distcc users may
have an interest in distinguishing between gcc jobs and everything
else.  I once messed with dictcc with very high job numbers and it
worked great when make hit a directory full of .c files, and not so
great when make/ant/whatever tried to run 50 instances of java in
parallel.

>    d) Source eclasses only once
>         Bug #422533 [19], gentoo-dev discussion [20]
>

Does anybody still want this included?  It seems to me like the list
discussion was leading in a different direction, but it isn't 100%
clear to me if this is the case.


>    e) HDEPEND: host dependencies for cross-compilation
>         Bug #317337 [21]
>

It isn't 100% clear to me which of the 14 proposed solutions in that
bug is the final answer, but I think it is DEPEND becomes target
depends, and HDEPEND is introduced as host depends.

Is the final intent that if HDEPEND isn't defined, then
HDEPEND=DEPEND, or does HDEPEND=""?

The ones I didn't mention seem basically fine as-is, or with the
tweaks already mentioned in the bugs.

Rich