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

[Jeremy Olexa]

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 :)
>
> 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
>
> Regards,
> Petteri
>

Thanks for gathering input from the dev community. I do not wish to 
respond to the monster thread (and won't).

Personally, I don't need the flexibility that glep55 provides for *my* 
ebuilds. The current scheme doesn't bother me. And actually, after doing 
some testing, I found that at least one of that packages/projects that I 
am involved in will need updating every time the extension changes (or 
some more broad change - I don't have time to investigate too much tbh). 
So, I would prefer that the file extension did not change [much/every 
eapi]. However, I can roll with the punches if it truely is needed. I 
also understand that some change is good in the long run even if it has 
some upfront cost to it.

However, in case that this discussion gets deferred until later, I would 
like to express that the Council should "request" (not demand) that 
portage adds support for the leading 2 ideas that result from the 
current discussion. This will allow us to not wait even longer when we 
are having this discussion in 2010 (hypothetically).

Thanks for listening, Petteri.
-Jeremy