On Tue, Jun 10, 2008 at 12:26:55PM -0400, Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has 
> USE flag depends in version 2.2 which is looming on the horizon. It'd be 
> nice to hit the ground running with supporting these. I know it'll be 
> trivial for the Paludis and pkgcore guys to make this work since they 
> already support USE flag depends.

The relevant bugs that should go into eapi2-

bug 211529 (econf == configure --disable-dependency-tracking 
  --enable-fast-install)
bug 205557 (export var/api indicating what sort of op this is- 
  replace, install, uninstall, for pkg_*)
bug 203891: STRIP_MASK; this would allow ebuilds to be fully unaware 
  of the strip implementation, although would require the var to be 
  in binpkg metadata (pkgcore specific request, since we allow 
  stripping of unstripped binpkgs)
bug 199722: use/useq; nail it down to one or the other imo.

Not bugged, but potentials for minor cleanup:
* drop AA (basically unused)
* drop RDEPEND=${RDEPEND-${DEPEND}}, unless there is a strong arg to 
  keep it (I recall a historical strong arg to punt it)
* identify any remaining portageq additions needed to allow 
  /var/db/pkg to change format

From the "proposed way back when but never got off the ground":
* USE mutually exclusive representation; fancy way of moving code like
 use foon && use !blah && die "blah must be enabled if foon is enabled"
 into a form that can be detected up front, instead of going 'boom' at 
 pkg_setup time.  This was originally proposed to address USE 
 configurations states for php pkgs, quick look, it still could be 
 useful.  Would be implemented via a new metadata key most likely.


Finally; it needs updating, but glep33 
(http://glep.gentoo.org/glep-0033.html) I'd be interested in trying to 
get into eapi2.  Currently, all managers support some form of env 
saving/restoration that the glep required, so that dependency is gone.  

What remains is basically updating the glep (I can do so), council 
agreement (presume non issue), and implementation- easy for pkgcore, 
presumably easy enough for paludis, easy for portage (already asked 
zac).

If glep33 went in, I'd suggest bug 197859: split 
src_configure/src_compile .  Without g33, holding off on 
src_configure/src_compile would likely be wise since it introduces 
some potentially nasty eapi related issues in eclasses.

Comments welcome.
~harring

Attachment: pgpNQ16S5rI9j.pgp
Description: PGP signature

Reply via email to