> Steve Long wrote: >> Ciaran McCreesh wrote: >>> Really. It's a heck of a lot cleaner in the filename suffix. >>> >> Nah, it's an awful hack and you know it. It has nothing to do with package >> naming and is unnecessary exposure of internal data. >
Forgive me if I missed this in the previous 500 emails, but I still don't quite understand why you can't just put EAPI="whatever" in the ebuild in a fixed place and leave it at that. The biggest objection to this that I've seen is that somebody might want to set it dynamically, which would be impossible to handle without sourcing it. However, you can't possibly put dynamic content in the filename (PLEASE let's not try!), so it sounds like we're stuck with fixed EAPI settings either way. So, why not just put it in the ebuild? If I were designing a binary file format I'd probably have a header with a version number in a fixed position, and a length-of-header field in a fixed position - then you could extend it all you want and old readers could either safely ignore it or at least know where the fields it understands are. Now, obviously we don't want to make every dev do anything like that on a manually-edited file. However, we could simply specify a simple format for the EAPI variable, and then have QA software (repoman/etc) make sure that it is in the correct format. Then it could be safely parsed with a regexp or whatever. Am I missing something?
smime.p7s
Description: S/MIME Cryptographic Signature
