* Re: [gentoo-dev] EAPI-2 - Let's get it started
@ 2008-06-11 3:34 99% ` Brian Harring
0 siblings, 0 replies; 1+ results
From: Brian Harring @ 2008-06-11 3:34 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
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 #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2008-06-10 16:26 [gentoo-dev] EAPI-2 - Let's get it started Doug Goldstein
2008-06-11 3:34 99% ` Brian Harring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox