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.
