Ciaran McCreesh wrote: > > Ok. What's the EAPI for the following ebuild that's written in an EAPI > that hasn't been published yet? And how would I extract it? > > # Copyright blah blah > > import vim-spell using language="en" >
Counterexample. How do you determine the eapi for the following file, which uses an EAPI that is yet unpublished - but which specifies that the EAPI NOT go in the filename: foo-1.2.ebuild Obviously if you go down one road, and then intentionally change things to go down another then old stuff won't work. Any package manager that depends on having the EAPI in the filename won't work if a decision is later made to remove the EAPI from the filename. Making a decision to put the EAPI in the filename for all time doesn't seem any less restricting than making a decision to put EAPI=1 or EAPI="1" in the ebuild for all time. And the latter is a whole lot less messy as far as I can see. So far the only objection I've seen to putting EAPI in the ebuild is that at some point in the future we might want to do it differently. Well, that is nice, but the same issue would apply to putting it in the filename - we could want to change that someday too. And if we put it in the filename why would we want to put it in a function or whatever inside the ebuild as well? Wouldn't that just be redundant. Sure, by not putting it in the filename we restrict ourselves a little from changing things later. However, if we do put in the filename we seem to already have a mass of folks who would want to change it RIGHT NOW. And if the whole point of this is to allow massive changes to ebuild format - why not wait until a need for such a change exists before instituting it. Why not defer this GLEP until it has some benefit and not just pain associated with it?
smime.p7s
Description: S/MIME Cryptographic Signature
