1 |
>>>>> On Sun, 18 Mar 2012, Ralph Sennhauser wrote: |
2 |
|
3 |
> If we want to keep .ebuild but avoid the compat issue another |
4 |
> variant would be "EAPI in header comment and one-time change of |
5 |
> ebuild location" or more formal: |
6 |
|
7 |
> 6 EAPI in header comment and one-time change of ebuild location: |
8 |
|
9 |
> - add a directory $CATEGORY/$PN/ebuilds to ebuild repositories. |
10 |
> - all files in $CATEGORY/$PN/ebuilds are ebuilds and are using a |
11 |
> well defined first line to denote the EAPI. |
12 |
> - For practical reasons the header should be a bash comment. PMs |
13 |
> shouldn't have to remove or skip first line from file for further |
14 |
> processing of ebuilds supporting bash comments. |
15 |
> - the .ebuild extension can be kept but could be changed if ever |
16 |
> desired. This due to the filename only having meaning if the |
17 |
> EAPI of the file is known. |
18 |
|
19 |
Similar ideas have been discussed before, in 2007 and 2009: |
20 |
<http://archives.gentoo.org/gentoo-dev/msg_fe3f0b9d050ead86aed9b42ce7ec93b0.xml> |
21 |
<http://archives.gentoo.org/gentoo-dev/msg_2e41942be33d8595cf7152aa91417fbe.xml> |
22 |
|
23 |
> Comparing this with GLEP 55 then this allows us to keep .ebuild in |
24 |
> return of some overhead with roughly the same pros and cons |
25 |
> otherwise, right? |
26 |
|
27 |
From a technical point of view, it's the same pros and cons. There are |
28 |
however non-technical aspects for all these propositions. For example, |
29 |
we would have to live with ebuilds in different directories for a long |
30 |
transition period (as we would have to live with two file extensions |
31 |
for a long time if we changed that). |
32 |
|
33 |
Ulrich |