Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-pms
Lists: gentoo-pms: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-pms@g.o
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: EAPI 3 PMS Draft
Date: Mon, 16 Mar 2009 20:47:17 +0000
I've got a very rough draft of what EAPI 3 might end up looking like,
based upon discussion:

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 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
* 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
  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 (PGP signature)
Re: EAPI 3 PMS Draft
-- Ciaran McCreesh
Lists: gentoo-pms: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Patches reloaded
Next by thread:
Re: EAPI 3 PMS Draft
Previous by date:
Re: Patches reloaded
Next by date:
Re: EAPI 3 PMS Draft

Updated Jul 18, 2012

Summary: Archive of the gentoo-pms mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.