On 13 March 2012 17:31, Brian Harring <ferri...@gmail.com> wrote:
> Worse, it actually makes parsing _worse_ than it already is. What G55
> had going for it was ease of filtering out unsupported eapi's.
> Literally just filter the readdir results. This behemoth Zac is
> proposing basically requires throwing regex at it, and *is* able to
> be tripped up since eapi's aren't strictly integers (1-prefix,
> 4-python, 4-eapi3 if I wanted to intentionally be a dick and break
> likely non-greedy implementations of the regex).
Eh? How? If you make "." a forbidden character in an eapi
specificiation, and make "." the delimiter
dev-foo/foo-bar-2.3.4.eapi5.eb
^^^^
How does that require regex?
remove the .eb , and the last token remaining is the eapi .
it doesn't clash with the existing system for 2 reasons, 1) the .eb
extension and 2) "eapi5" is not a valid version token
> Same angle, embedding it into the version space means that there can
> be conflicts w/ PN.
I'm confused as to how, can you give one theoretical example?
dev-foo/foo-bar-2.3.4.eapi5.eb <-- eapi5 can't be a package name
here, because its got the .eb suffix which means an EAPI *MUST* be
specified
and eapi5 also can't be a package name there, because then you're
telling be it tokenizes as:
category=dev-foo
package=foo-bar-2.3.4.eapi5
version = undefined
eapi = undefined
Which is clearly illegal.
> Basically... embedding it into the versioning like that, besides being
> ugly as all hell, discards the main benefit g55 had- clear
> identification of EAPI.
It still seems "clear" to me.
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
