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