Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 27 Dec 2007 18:11:33 +0000:
> On Thu, 27 Dec 2007 18:03:27 +0000 > Roy Marples <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] mailing list
