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

[Ferris McCormick]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@g.o> 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

This is GLEP-55 I think, and it is my preference.  It seems to solve
the problem that the glep sets out to solve and has no effect on
current portage.    I don't claim that it's beautiful or perfect, but I
have not seen a better alternative, either.  It also has going for it
the fact that some number of people have already thought through it and
Piotr went to the effort of writing it up as a proposal, so it has had
more thought put into it than alternatives.  I do not find the
arguments against it persuasive, so I'd say do this and be done with
it.  We can argue forever for better alternatives, but I don't see that
we are getting very far with that approach.  Just my opinion, of course.

>   b) .<eapi>.ebuild
>     - current Portage does not work with this
>   c) .<eapi>.<new extension>
>     - ignored by current Portage

This one's OK with me, too, if people prefer it.

>
> 3) EAPI in locked down place in the ebuild

I generally dislike this sort of thing, and I think it puts more of a
strain of the ebuild developers.  But then, I'm not an package
developer, so my opinion with respect to this is not worth much.  I'd
just rather see the EAPI visible in the file name than have to read the
ebuild to find it, and I guess the overhead argument is that it's
easier on portage not to have to do that, too.

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

I don't see why this is better than the glep 55 proposal???

>   b) new subdirectory like ebuilds/

Yuch.

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

Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmccor@g.o>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)