[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> posted
20071227181133.28ff5684@×××××××××××××.uk, excerpted below, on  Thu, 27 Dec
2007 18:11:33 +0000:

> On Thu, 27 Dec 2007 18:03:27 +0000
> Roy Marples <roy@×××××××.name> wrote:
>> On Thu, 2007-12-27 at 17:43 +0000, Ciaran McCreesh wrote:
>> > Or to put it another way, you're objecting to painting the house pink
>> > rather than green because you don't like pink (because your last
>> > house was green too), ignoring that it's been demonstrated that when
>> > painted green, it's impossible to add a conservatory and central
>> > heating because the green paint will catch fire and kill everyone.
>>
>> Using your analogy you should then recognise that there is a strong
>> dislike for pink and should seek a new colour that allows the building
>> of said extensions.
>
> And what colour would that be? We've already ruled out purple, brown and
> yellow, and no-one has yet found any other colour of paint.

OK, I still think putting it in the file name is less prone to error, but 
what about this, call it "blue" if you will?

1) Strictly define and restrict EAPI to a specific form in a specific 
file location (say EAPI=value, unquoted, as the first line of the file).

2) Quickly define say EAPI=1_ext, that further defines say SUB_EAPI, or 
EBPI, or EAPI-B, which is allowed to be a function or whatever, with the 
only further restrictions on it being those that would apply to EAPI-
suffix file names.

That should give us the nailed down qualities of putting it in the file 
name, while providing the flexibility therein as well.  There may be a 
bit of delay while we wait for non-EAPI aware PMs to drop out, but by the 
sounds of things, it's not going to be much more than fighting this thru 
and getting it approved is likely to be (a couple months, anyway), and as 
it's a different EAPI, EAPI aware PMs should ignore it if they don't 
understand it.  PMs can then do a pre-parse, looking at the first line in 
specified format just as they'd otherwise look at the filename.  With 
that information in hand, if the EAPI is 1_ext and they understand that, 
they'll immediately know to check SUB_EAPI or whatever, which is as 
flexible as bash parsing is.  If at some point in the future we want to 
go to XML based formats or whatever, we cross that bridge when we come to 
it and /then/ we do the filename thing, if it's still thought to be 
necessary.  Meanwhile, other (master) EAPIs may yet be defined, if their 
practical use is restricted enough to fit within the strict first line 
EAPI=whatever rule above, and those could include further refinements on 
the SUB_EAPI theme if they become necessary, WITHOUT a multiplication if 
ebuild-xxx extensions.

The big drawback I see here is the the forced delay until EAPI aware PMs 
can be assumed, but as I said, it seems that's going to be the case with 
the current proposal anyway, simply because of the amount of resistance 
to it and the delay in approval that's likely to mean, even if it /is/ 
ultimately approved.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list