Petteri Räty wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a useful
> experiment to see if we can control ourselves :)
> 

Thank you Petteri. I knew there was a reason I voted for you.

> 
> 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

a) then c).  I personally think b) is a bad idea that will just slow the
implementation of this even more.

> 
> 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

If it really comes to it  b)?  Tho it leaves a bad taste in my mouth.

> 
> Regards,
> Petteri
>