Here's why I think you can't -- or at least shouldn't -- put EAPI into the filename.
>From your EAPI definition: > A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the > cat/pkg-ver as a whole, and is static across that cat/pkg-ver. It's clearly NOT the purpose of a filename to describe how the contents of a file are structured/formatted/encoded/etc. It's sole purpose is to uniquely identify a file. Example: I use .txt to identify my text documents. However, I don't use .txt-utf-8, .txt-latin-1, .txt-iso-8859-15 just because their encoding differs. As cat/pkg-ver ultimately is ONE file in the filesystem, there's no reason to put any information about the EAPI in the filename. I still don't get why EAPI=xxx is soooo bad. Obviously the GLEP (and the last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is bash syntax. If you just don't like EAPI being defined as variable (because future EAPIs could define that EAPI is assigned via a function), there are other ways to put this into the ebuild. Eg. Python PEP 0263 ([1]) proposes a way to declare the encoding inside of the source file. Same could be done for the EAPI. Or just write a GLEP that states EAPI has to be assigned via the EAPI variable. You're trying to *set* a standard here, so act accordingly. thomas [1] http://www.python.org/dev/peps/pep-0263/ -- [EMAIL PROTECTED] mailing list
