Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Caleb Cushing <xenoterracide@gmail.com>]

On Tue, Feb 24, 2009 at 5:21 PM, Petteri Räty <betelgeuse@gentoo.org> 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
>

I don't see the point of some of these... a shorter extension would be
nice but not really necessary.

.<eapi>.ebuild

so like .2.ebuild 'cause that'd work great?
smith-1.3.6.2.ebuild  better yet vanilla-sources-2.6.28.2.2.ebuild

yeah I can see that working out... no it wouldn't

or maybe smith-1.3.6.eapi-2.ebuild

just too long

here's an idea, perhaps not a great one... but perhaps it'll make
someone else think...

how about this on the first line

# eapi-2

and instead of sourcing it, have portage match it with a regex first,
figure out the eapi, then source it.

I don't know if I really like like what I'm proposing, but I don't see
anything else that looks good.
-- 
Caleb Cushing

http://xenoterracide.blogspot.com