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