| 1 |
On Tue, Jun 10, 2008 at 12:26:55PM -0400, Doug Goldstein wrote: |
| 2 |
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has |
| 3 |
> USE flag depends in version 2.2 which is looming on the horizon. It'd be |
| 4 |
> nice to hit the ground running with supporting these. I know it'll be |
| 5 |
> trivial for the Paludis and pkgcore guys to make this work since they |
| 6 |
> already support USE flag depends. |
| 7 |
|
| 8 |
The relevant bugs that should go into eapi2- |
| 9 |
|
| 10 |
bug 211529 (econf == configure --disable-dependency-tracking |
| 11 |
--enable-fast-install) |
| 12 |
bug 205557 (export var/api indicating what sort of op this is- |
| 13 |
replace, install, uninstall, for pkg_*) |
| 14 |
bug 203891: STRIP_MASK; this would allow ebuilds to be fully unaware |
| 15 |
of the strip implementation, although would require the var to be |
| 16 |
in binpkg metadata (pkgcore specific request, since we allow |
| 17 |
stripping of unstripped binpkgs) |
| 18 |
bug 199722: use/useq; nail it down to one or the other imo. |
| 19 |
|
| 20 |
Not bugged, but potentials for minor cleanup: |
| 21 |
* drop AA (basically unused) |
| 22 |
* drop RDEPEND=${RDEPEND-${DEPEND}}, unless there is a strong arg to |
| 23 |
keep it (I recall a historical strong arg to punt it) |
| 24 |
* identify any remaining portageq additions needed to allow |
| 25 |
/var/db/pkg to change format |
| 26 |
|
| 27 |
From the "proposed way back when but never got off the ground": |
| 28 |
* USE mutually exclusive representation; fancy way of moving code like |
| 29 |
use foon && use !blah && die "blah must be enabled if foon is enabled" |
| 30 |
into a form that can be detected up front, instead of going 'boom' at |
| 31 |
pkg_setup time. This was originally proposed to address USE |
| 32 |
configurations states for php pkgs, quick look, it still could be |
| 33 |
useful. Would be implemented via a new metadata key most likely. |
| 34 |
|
| 35 |
|
| 36 |
Finally; it needs updating, but glep33 |
| 37 |
(http://glep.gentoo.org/glep-0033.html) I'd be interested in trying to |
| 38 |
get into eapi2. Currently, all managers support some form of env |
| 39 |
saving/restoration that the glep required, so that dependency is gone. |
| 40 |
|
| 41 |
What remains is basically updating the glep (I can do so), council |
| 42 |
agreement (presume non issue), and implementation- easy for pkgcore, |
| 43 |
presumably easy enough for paludis, easy for portage (already asked |
| 44 |
zac). |
| 45 |
|
| 46 |
If glep33 went in, I'd suggest bug 197859: split |
| 47 |
src_configure/src_compile . Without g33, holding off on |
| 48 |
src_configure/src_compile would likely be wise since it introduces |
| 49 |
some potentially nasty eapi related issues in eclasses. |
| 50 |
|
| 51 |
Comments welcome. |
| 52 |
~harring |
Archives