Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky <michael@orlitzky.com>]

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 <michael@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.