Re: [gentoo-dev] PMS EAPI 3 more or less ready

[Tiziano Müller]

Am Sonntag, den 12.04.2009, 20:59 +0100 schrieb Ciaran McCreesh:
> I've got the EAPI 3 branch for PMS more or less ready:
>
>     http://github.com/ciaranm/pms/tree/eapi-3
>
> The provisional included feature list is everything that was ready
> before the deadline.
Thanks a lot for your work.
Sorry, I was quiet busy the last week with real life.

>
> Before the next Council meeting (ideally a week before, so we've got
> time to get the questions worked out), I'd appreciate it if every
> Council member could go through each item on the list below, check its
> description in PMS (Appendix E has a handy list of links to the
> relevant text, or look for the boxed labels in the margin) and
> provisionally mark it as one of:
>
> * critical: EAPI 3 needs to be held up until this feature is in Portage.
>
> * yes: This feature should be in EAPI 3, but can be dropped if it turns
>   out it's going to take ages to get into Portage.
>
> * no: This feature shouldn't be in EAPI 3.
>
> * whatever: You have no strong opinion on whether this feature should
>   be in EAPI 3.
>
> * query: You have questions about this feature, or you think parts of
>   it need discussion, or you've found a mistake in the PMS draft.
>
> I'll try to address any queries as they come so people can update their
> opinions.
>
> I'd also appreciate any review of wording features from anyone else.
> There are probably still a few holes.
>
> Hopefully we can get a final list decided upon and provisionally
> approved by the next Council meeting, and then as soon as Portage is
> ready to go we can merge everything into PMS proper and get a signed
> approval tag as we did for EAPI 2.
>
> Here's the list:
>
> * PKG-PRETEND
critical.

> * SLOT-OPERATOR-DEPS
critical.

> * USE-DEP-DEFAULTS
critical.

> * DEFINED-PHASES
critical.

> * PROPERTIES
critical.

> * SRC-INSTALL
critical.

> * CONTROLLABLE-COMPRESS
no.

> * DODOC
critical.

> * DOINS
critical.

> * ANY-USE
yes.

> * BANNED-COMMANDS
yes.

> * DOEXAMPLE
whatever.
... with dodoc getting recursive behaviour I guess this is not really
critical. If portage penalizes it's users by compressing those examples,
that's their problem.

> * DOINCLUDE
yes.

> * UNPACK-EXTENSIONS
yes.

> * ECONF-OPTIONS
yes.

> * PKG-INFO
critical.

> * PROFILE-IUSE-INJECTION
yes, but *_IMPLICIT has to be discussed.

> * AA
yes.

> * KV
yes.

> * REPLACE-VERSION-VARS
critical.

> * S-WORKDIR-FALLBACK
yes.

> * UNPACK-IF-COMPRESSED
yes.

> * RDEPEND-DEPEND
critical.

> * DIE-ON-FAILURE
yes.

> * NONFATAL
yes.

>
> Some answers to existing queries that I can remember:
>
> * DEFINED-PHASES and PROPERTIES have to be EAPI linked because of the
>   metadata cache.
>
> * ANY-USE is already special cased in the package manager and
>   specification. Everywhere that's using it is doing it wrong. It's
>   possible to rewrite the dep to mean same thing using an expanded
>   form, although it'll still be impossible to use it correctly if you
>   do that.
>
> * ECONF-OPTIONS is very unlikely to break custom configure scripts. We
>   already pass various weird things through econf, so any configure
>   script that dies on unrecognised options is probably going to break
>   anyway. No-one's managed to name a configure script that would be
>   broken by this change that isn't already not using econf anyway.
... or using econf even if it shouldn't.