Re: [gentoo-dev] Re: The fallacies of GLEP55

[David Leverton <levertond@googlemail.com>]

On Saturday 16 May 2009 13:14:23 Duncan wrote:
> I mean, for the longest time, the main (among many) boosting claim seemed
> to be that the speed difference between in-file and in-filename made the
> former prohibitive in practice.

No, performance was never the point of GLEP 55.  People like to talk about it 
because, as we all know, Gentoo is for ricers, but it's not relevant and 
never has been, except to the extent that we don't want to make performance 
worse than it is now.

> The argument was originally made that a simple highly specified EAPI=
> declaration in the file itself was too restrictive of all the ways it
> could be specified now -- until it began to be pointed out every time the
> argument was made that the filename method was very similarly
> restricted.

No, no-one has ever claimed that the restricted EAPI= method is bad because 
they /want/ to be able to set it using weird bash tricks.  The problem is 
that, if it appears as a bash assignment you /can/ set it using weird bash 
tricks, and making the PM's own parsing accept a subset of what can happen 
when the ebuild /is/ eventually sourced is going to make a mess.

> I'd argue no, it's no more unintuitive than any other format definition
> choice.  It's the basic format definition, using the long accepted method
> of "magic values" at a "magic location" to define the format version.
> That's very basic definitional, restricted only to the degree necessary
> for practical application of the definition.  Therefore, it's not
> unintuitive, or at least, certainly no more so than arbitrarily defining
> it to be in the filename instead, because "intuitive" now gets defined by
> the format definition at an extremely basic level, well below the level
> at which all the "intuitive or not" fancy stuff gets addressed.

"The format definition at an extremely basic level" is bash, which has no such 
restrictions.

For comparson, another alternative that some people have suggested is putting 
it in a specially formatted comment.  This avoids the issue I mentioned 
because bash doesn't try to parse those at all, so the only rules are those 
that specify what format the comment should be in.  On the other hand, this 
isn't backwards compatible with current package managers.