On Sat, 22 Dec 2007 16:23:13 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > On 2007/12/22, Ciaran McCreesh <[EMAIL PROTECTED]> > wrote: > > The filename solution is by far the best -- it's the only one that > > hasn't had any technical objections raised to it. > > And can you remind us what technical objection, if any, has been > raised against the "EAPI set in contents with enough syntaxic > restrictions to allow its extraction without sourcing, and the files > names extension changing only if this rules have to change" > alternative?
a) It's a massive restriction on what future ebuilds can do. b) It's a massive restriction on what current ebuilds can do. c) It's an extremely bizarre restriction, the likes of which do not currently exist, that will confuse the hell out of all the people that don't realise that such a restriction exists. d) It introduces a new prepass parse layer to an already complex process. e) The Portage guys said no to it. > So, once more to make it clear: yes, the current ".ebuild" extension > would have to change into ".something" if we want to introduce such a > solution without waiting N months. The difference with > ".ebuild-$EAPI" being that ".something" would then stay unchanged for > numerous later EAPIs You keep saying that like *.ebuild-3 and *.ebuild-4 are massively different. They're not. They're the same extension, decorated slightly differently. > (until some unlikely conditions are met, like a switch away from Bash > format). Or until we do something about eclasses and EAPIs, or until we do something about storing metadata outside of the ebuilds themselves... -- Ciaran McCreesh
signature.asc
Description: PGP signature
