Re: [gentoo-dev] GLEP 55 updated

[Ben de Groot]

Let me first say that I think this revision is much improved, and makes
it clearer what we are talking about.

As to the stated problem(s):

1. "Incompatible change of inherit (e.g. make it look in the package dir
too)"
A case would need to be made, in my opinion, as to why we would wish to
allow this in the first place. The current inherit behavior with
eclasses in a central place works well enough. So I think we can
disregard this.

2. "Add new global scope functions in any sane way"
This is a valid use case, as seen by the eapi-2 update. But the way this
is currently handled by portage (advising to upgrade the package
manager) works. So I don't see a need to change the file extension for
this reason.

3. "Extend versioning rules in an EAPI - for example, addition of the
scm suffix - GLEP54 [1] or allowing more sensible version formats like
1-rc1, 1-alpha etc. to match upstream more closely."
Apart from GLEP54, I believe our versioning scheme works reasonably
well. I don't see any need to match upstream more closely. I'd rather
like to keep the more uniform way of handling suffixes like rc and
alpha, that we have now.
GLEP54 is a valid use case, and I can see the value in that. Even so,
using -9999 and variations has worked for us so far, so I'm not
convinced GLEP54&55 as a package is a must have.

4. "Use newer bash features"
This, in my opinion, would potentially be very useful to have. Altho it
is certainly possible to continue with bash 3.0 as we have done so far,
certain newer features are nice to be able to use.

All in all I am still not sold on the perceived problems, and therefor a
solution is in my eyes not strictly necessary. Having said that, I do
understand people wanting support for newer bash features and GLEP54, so
let's look at the possible solutions that have been proposed.


Jorge Manuel B. S. Vicetto wrote:
> Ulrich Mueller wrote:
>>>>>>> On Sun, 17 May 2009, Denis Dupeyron wrote:
>>> 2009/5/17 Piotr Jaroszyñski <peper@g.o>:
>>>> 1. EAPI-suffixed ebuilds (obviously)
>>>> 2. EAPI in the filename with one-time extension change
>>>> 3. Easily fetchable EAPI inside the ebuild and one-time extension change
>> I'm strongly against 1 and 2 (no need to repeat the old arguments
>> here), but I could live with 3.

Me too.

>>> My preference goes to 3 with a .eb extension and EAPI on the first line.
>> Make this "the first non-empty non-comment line".
>
> As others have commented, we should probably make this the last comment
> line in the header. Any suggestions for a specific identification string
> or do we simply use '# EAPI="X"' or use a she-bang '#!/<..> EAPI="X"' ?

In this case, I'd prefer .eb extension as well. EAPI to be somewhere
near the top, I don't care that much about the exact implementation.

>> Looks like ".eb" is already taken by some exotic commercial
>> application, but I think we can ignore this.
>
> I like .eb but could also live with .gebuild as was suggested before.

I'd rather go for .geb as second choice. I'd rather go shorter than longer.

Robert Buchholz wrote:
> Judging from this list, fourth option present in the GLEP is
> unacceptable for you?
> 4. Easily fetchable EAPI inside the ebuild
>
> From what I understand, the difference between 3 and 4 is that
>
> (4) would break pre-glep55 Portage versions that see an ebuild with no
>     metadata cache present if the ebuild uses a future EAPI that
>     introduces changes as described in the "Current behaviour" section.
> (4) would otherwise keep the current workflow the same except
>     restricting the way the EAPI variable is defined in the ebuild.
>
> I would argue that most people who are be exposed to repositories that
> do not carry a metadata cache (overlays) which use new EAPIs also keep
> their portage version current. I'd say go with option (4) now and by
> the time EAPI 4 is collected, written up, agreed upon and implemented,
> enough time went by so we would not have to introduce an artificial
> delay.
> And after that, there won't be any delay to avoid breakage anymore.

This would still have my preference.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________