Thu May 21 09:45:54 CEST 2009
Revising history
Y'know, whatever I said about GLEP55 in my last blarghpost isn't relevant anymore.
The current version (1.3) does not mention the things I criticized in the old version (1.2). Maybe they'll be there again in the version up for council discussion next time.
Who knows :)
Because of that I feel the need to point out that any discussion of GLEPs is problematic if one doesn't add the version so we all know what is being talked about (but that doesn't appear to be what people want, next you'll ask for Facts and Logic! Bah!)
The current version (1.3) does not mention the things I criticized in the old version (1.2). Maybe they'll be there again in the version up for council discussion next time.
Who knows :)
Because of that I feel the need to point out that any discussion of GLEPs is problematic if one doesn't add the version so we all know what is being talked about (but that doesn't appear to be what people want, next you'll ask for Facts and Logic! Bah!)
Sat May 16 19:33:13 CEST 2009
Oops, I did it again
Here's a brilliant little thing I found by accident:
So for anyone who hasn't noticed, this is a backdoor that invalidates the assumption that the filename represents the actual EAPI. In other words, you'll have to parse the ebuild anyway to find the actual EAPI, the filename is just a hint - which means that you don't gain anything over the current situation.
Now if you were to put the EAPI into a string which is near the top of the file and has to contain the EAPI in unambiguous terms (no shell expansion, variable substitution or other trickeries) you would actually have less work to extract the EAPI (because you do not have to source the ebuild, as a few people have pointed out) and you can keep one file extension so that tools don't have to guess if that whargharbl over there is an ebuild or not.
Oh, I forgot. Current behaviour and QA policies suggest to put the EAPI near the top in an unambiguous string anyway!
Le Sigh!
Specification Ebuild filename extension syntax: ebuild[-That is from GLEP55], where [] denotes an optional part, and is the EAPI of the ebuild. Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps: If the pre-source EAPI is not set it defaults to 0. If the pre-source EAPI is not recognised it is returned immediately. If the post-source EAPI is not set, it defaults to the pre-source EAPI. post-source EAPI is returned.
So for anyone who hasn't noticed, this is a backdoor that invalidates the assumption that the filename represents the actual EAPI. In other words, you'll have to parse the ebuild anyway to find the actual EAPI, the filename is just a hint - which means that you don't gain anything over the current situation.
Now if you were to put the EAPI into a string which is near the top of the file and has to contain the EAPI in unambiguous terms (no shell expansion, variable substitution or other trickeries) you would actually have less work to extract the EAPI (because you do not have to source the ebuild, as a few people have pointed out) and you can keep one file extension so that tools don't have to guess if that whargharbl over there is an ebuild or not.
Oh, I forgot. Current behaviour and QA policies suggest to put the EAPI near the top in an unambiguous string anyway!
Le Sigh!