* Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
@ 2009-02-25 12:49 99% ` Brian Harring
0 siblings, 0 replies; 1+ results
From: Brian Harring @ 2009-02-25 12:49 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage
>
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait
4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as
the first statement (simplest way).
pros:
- global scope changes can occur (inherit mechanism changes
included).
- expanding on the first, auto inherits (pkg level) are possible-
effectively when eapi gets invoked the manager is in control and
can do whatever is desired setting up the env wise.
- bash version requirements can be leveled (bash parses as it goes,
meaning that essentially it won't parse what follows 'eapi 2' till
that command statement finishes)
- fits w/ the existing semantics nicely enough.
cons:
- mangling the version rules for pkgs still isn't possible; no -scm.
Arguable if -scm is even desired, but being explicit about it not
covering this.
- transition is slightly icky; basically one of the following is
required-
a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason
for this is that current managers obviously lack an eapi function,
to make managers available *now* blow up the || die is required.
This solution can be deployed now, no transition required although
at some point stating "eapi is required retroactively for all
eapis" would be wise to eliminate the need for the || die (cut
support basically for old managers)
b) bashrc trickery, defines an eapi if it's unset. Said eapi
function exports EAPI=$1, optionally triggering a die if the eapi
isn't 0,1,2 (since any later eapi would require a manager upgrade
which would also have the eapi function).
Personally, if g54 is ixnayed #4 I tend to think is the best option
out there- if g54 is forced in, g55 (or at least something that
adjusts the extension to make it invisible to current managers) is
required.
Commentary? Tend to think #4 is the most aesthetically pleasing to
folk, but who knows...
~harring
[-- Attachment #2: Type: application/pgp-signature, Size: 197 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 --
2009-02-24 22:21 [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Petteri Räty
2009-02-25 12:49 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