On 03/09/12 13:56, Zac Medico wrote: > On 03/09/2012 10:33 AM, Michael Orlitzky wrote: >> On 03/09/12 13:02, James Broadhead wrote: >>> On 9 March 2012 17:31, Michael Orlitzky <mich...@orlitzky.com> wrote: >>>> At any rate, I'm now convinced that we all want GLEP 55, but with a >>>> different name. >>> >>> I think that moving the data to the filename is probably a better >>> approach than semi- or repeat parsing, but I prefer preserving the >>> .ebuild extension, and think that eapi should be specified similarly >>> to ebuild revision, as a suffix. for instance: >>> >>> app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the >>> new schema) >>> app-foo/bar-1.0.0-r1-e1.ebuild >>> app-foo/bar-1.0.0-r1-e99.ebuild >>> >> >> One of the benefits of GLEP 55 naming is that old package managers won't >> try to parse them. So, for example, if we put new features in, >> >> app-foo/bar-1.0.0.ebuild-5 >> >> portage from 2003 won't try to source it. > > Every software product has an end of life. I think if a system hasn't > been updated in the last 2 years or so, then it's fair to assume that it > will never be updated. So, all relevant versions of portage should > simply show a warning message if the encounter an ebuild name such as > "app-foo/bar-1.0.0-r1-e99.ebuild".
I was just repeating your point against the eapi function =) And there is a non-zero benefit to it, I've had to rescue systems that haven't seen an update in years. The best reason I can think of for using ebuild-EAPI is simply semantic. The basename of the ebuild refers to the package, the extension decides what interprets it. That is at least consistent with every other file extension.
