I've got a very rough draft of what EAPI 3 might end up looking like, based upon discussion:
http://github.com/ciaranm/pms/tree/eapi-3
Note that I will probably rebase and modifying the branch quite a bit,
so if you don't know how to deal with that when using git, don't track
it.
It should be one commit per feature, which makes it fairly easy to
remove anything that ends up not making it, and very easy to see what's
proposed, which currently looks like this:
* Introduce eapi 3
* Rework tables for EAPI 3.
* EAPI 3 has pkg_pretend.
* EAPI 3 supports slot operator dependencies
* EAPI 3 has use dependency defaults
* PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
* EAPI 3 has a default src_install
* EAPI 3 has controllable compression and docompress
* EAPI 3 has dodoc -r
* EAPI 3 requires doins support for symlinks
* EAPI 3 bans || ( use? ( ... ) )
* dohard and dosed banned in EAPI 3
* doinclude, newinclude for EAPI 3
* EAPI 3 supports .xz, .tar.xz
* EAPI 3 has more econf arguments
* EAPI 3 supports pkg_info on installed packages
* USE is stricter in EAPI 3
* Note that (+) won't work on USE_EXPAND etc things
* AA, KV gone in EAPI 3
Still to work out:
* The exact details for the new USE restrictions. In particular, do we
want IUSE_IMPLICIT? We'll also need an accurate list of all
possible values for things like LINGUAS.
* The [use(+)] thing. For various really pesky reasons, there's no way
things like [video_cards_radeon(+)] can be expected to work when
applied against EAPIs before 3, but it can be made to work if we know
it'll only ever be applied against things with EAPI 3 or later. Is it
easier to just say it's never allowed, though?
* What's a doexample?
* What's default_src_install going to do? I've seen a load of
variations. It looks like our choices are between things that ignore
docs, making it largely worthless, or things that use a DOCS
variable, which Donnie hates (despite making extensive use of such
things himself in eclasses).
* "Provide ebuilds a way to differentiate between updates and
removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION,
but I've not had any feedback on that.
* "Utility commands, even the ones that aren't functions, should die.".
Is Portage likely to be able to do this in the timeframe we're after?
* "Calling unpack on an unrecognised extension should be fatal, unless
--if-compressed is specified.". There've been questions on this, but
no obvious outrage. Is this in or out?
* I've left out killing off dohtml. Was a decision reached on that?
* RDEPEND=DEPEND is still in. Again, was a decision reached?
* xz is in, but do we really want to do that when there appears to be
nothing stable that can deal with xz? lzma going in was a mistake
caused by people being too eager here in exactly the same way they
were for making Portage handle xz...
* Am I to take it src_test is to remain in its current worthless state?
I've probably missed some more things, but I don't know what they are,
so if anyone can find any please list them.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
