[gentoo-pms] EAPI 3 PMS Draft

[Ciaran McCreesh]

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