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 <pe...@gentoo.org>: >>>> 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 ______________________________________________________
