On 03/09/2012 08:33 AM, Eray Aslan wrote: > On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote: >> They may or may not have issues. Our goal is to minimize our >> vulnerability to these kinds of issues as much as possible. Being able >> to obtain the ebuild EAPI without the expense of sourcing it is one >> small step toward this goal. > > EAPI is metadata and is best treated as such. In other words, history > aside, it does not belong inside an ebuild. Making EAPI info part of > the filename does look like a reasonable solution - similar to > seen/replied flags in the filenames in maildir directories. Heck, even > version numbers in an ebuild filename is similar. > > I don't understand why there is a strong objection to it.
I have a mild preference for the "parse EAPI assignment" approach, simply because it's the least invasive. That said, ultimately it doesn't make much difference to me whether we parse it from inside the ebuild or from its file name. From my perspective, arguing between these approaches boils down to hair-splitting [1]. [1] http://en.wikipedia.org/wiki/Trivial_objections -- Thanks, Zac
