On 2007/12/23, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > a) It's a massive restriction on what future ebuilds can do.
- it handles a reasonnable range of likely future EAPIs, - it includes the "extension changes when the way to extract EAPI has to change" to avoid bounding future EAPIs to this range. > b) It's a massive restriction on what current ebuilds can do. Current ebuilds are the one with the ".ebuild" extension. I'm not proposing any change to the way they are handled. Now, if you mean that there are some stuffs allowed in ".ebuild" files which would no more be allowed in the ".something" files, then yes: it introduces some restrictions on how the EAPI is declared. That's how it works. It has yet to be shown that this restrictions fordbids anything else than some pointless code (like setting EAPI depending on $PV), and furthermore that this code would, at the contrary, play well with the GLEP 55 approach (obviously not the case with the previous pointless example). > 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. Devs are already used to follow numerous conventions in the way they format their ebuilds. While this restriction is more than a convention, I assume that's how it will be followed by many people: just doing things the way they are in "skel.something". And for those who happen to break the rule because they edited a ".something" file without knowing what it was, they would learn as soon as they test/use their file (no need to wait for the repoman step, it would be checked whenever the ebuild is sourced). > d) It introduces a new prepass parse layer to an already complex > process. Both solutions add some new steps to this process, and it doesn't look to me like there's a significant difference beetween their respective added complexity. That said, you're the PM dev here, not me, so if you confirm that implementation of an in-contents solution is significantly harder, then i will accept the argument. > e) The Portage guys said no to it. When/where? I've only seen Marius commenting here, but not on that aspect. Also, i've read this 2005 "EBUILD_FORMAT" discussion that Steve Long has pointed [1], where Brian was against non-Bash parsing, but: - he was against changing files extension too, - the flaws in the EAPI system designed at this time is what led to rethinking it now. If i've missed something since then (and that's likely), could you give me a pointer to the archives? Thanks. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/29512 > You keep saying that like *.ebuild-3 and *.ebuild-4 are massively > different. They're not. They're the same extension, decorated slightly > differently. To me they look different enough that it's worth avoiding them if possible (especialy considering the decoration is not just an integer). I absolutly agree that it's a futile and subjective objection to GLEP 55, but so far, and until you answer to what i've left open above, it's the only aspect on which i can think one solution is better than the other. > > (until some unlikely conditions are met, like a switch away from > > Bash format). > > Or until we do something about eclasses and EAPIs, If you're not more specific about this "something", it's hard to say what solution will handle it best. For example, it could be nice that some ebuilds which are just instanciation of an eclass (like the vim-spell-* ones) let their eclass decide what EAPI it needs. That's something which could be handled nicely by a backward-compatible extension of the EAPI-in-contents approach: # Copyright... eapi inherited:vim-spell-2 VIM_SPELL_LANGUAGE="French" inherit vim-spell-2 (the "-2" here is not a specific EAPI, it's just that the "vim-spell" eclass already exists and that it would not be a good idea to apply the needed changes to it) PMs which know how to handle such redirection would then go look for an EAPI declared in the eclass before sourcing the whole thing. PMs which don't yet would see it as an unsupported EAPI and stop there. My point here is that the in-contents alternative is just a syntaxic rule which defines a first-pass extraction of a value from an ebuild file (as opposed to an ebuild file name extension). How it is then used (what the "eapi" function does, if anything, or whether this value is the definitive EAPI, or how EAPI vs. eclasses is handled, etc.) can be subject to future changes depending on this value. That's part of why this solution is not more restrictive than the file name extension approach. > or until we do something about storing metadata outside of the ebuilds > themselves... # Copyright... eapi from-external-metadatas ... I agree there's an unecessary performance impact on doing that though, so you're right that it's a case where changing the file extension would be better. The EAPI declaration would be moved together with the other metadatas, and its a whole new family of EAPIs which would fall under this single new file name extension. -- TGL. -- [EMAIL PROTECTED] mailing list
