I've got the EAPI 3 branch for PMS more or less ready:
http://github.com/ciaranm/pms/tree/eapi-3The provisional included feature list is everything that was ready before the deadline. 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 * SLOT-OPERATOR-DEPS * USE-DEP-DEFAULTS * DEFINED-PHASES * PROPERTIES * SRC-INSTALL * CONTROLLABLE-COMPRESS * DODOC * DOINS * ANY-USE * BANNED-COMMANDS * DOEXAMPLE * DOINCLUDE * UNPACK-EXTENSIONS * ECONF-OPTIONS * PKG-INFO * PROFILE-IUSE-INJECTION * AA * KV * REPLACE-VERSION-VARS * S-WORKDIR-FALLBACK * UNPACK-IF-COMPRESSED * RDEPEND-DEPEND * DIE-ON-FAILURE * NONFATAL 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. -- Ciaran McCreesh
signature.asc
Description: PGP signature
