1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 12/03/12 02:50 PM, Ulrich Mueller wrote: |
5 |
>>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote: |
6 |
>> GLEP 55 is simple, it solves all the problems we have (including |
7 |
>> the version issue, which everyone is conveniently ignoring), it |
8 |
>> doesn't require us to guess what's going to happen next and it |
9 |
>> can be implemented immediately. That's a rather big deal. |
10 |
> |
11 |
> The "header comment" solution solves all these issues too, without |
12 |
> embedding unrelated information in the filename [1]. It can be |
13 |
> implemented immediately, too. |
14 |
> |
15 |
> The argument that was always used against such solutions was that |
16 |
> it would "hurt performance". However, when the council asked for |
17 |
> benchmarks that would prove that point, nobody could provide them. |
18 |
> |
19 |
> Ulrich |
20 |
|
21 |
|
22 |
Regarding the filename issue, and the potential in the future for |
23 |
ebuilds that get parsed with other parsers: |
24 |
|
25 |
Is there any particular reason why we would want multiple ebuilds for |
26 |
a package to exist for the same version, but supporting different |
27 |
EAPIs (ad therefore different parsers)? |
28 |
|
29 |
If the answer to this is no, that there should always be only one |
30 |
ebuild per package version, then chances are good that we should keep |
31 |
the eapi (or other identifier) out of the file name. However, if the |
32 |
answer is yes, then the filename method is probably the cleanest way |
33 |
to do this. |
34 |
|
35 |
-----BEGIN PGP SIGNATURE----- |
36 |
Version: GnuPG v2.0.17 (GNU/Linux) |
37 |
|
38 |
iF4EAREIAAYFAk9eRzkACgkQAJxUfCtlWe18WwD5AeXETH+J4X8d8P7TX76FPGPS |
39 |
0vS2rrRZktpLp70TkcQA/0Cl2/OdSlfwi0CqC8IBJffsY3epXkqxhzPL8bwsNAoj |
40 |
=Q5aK |
41 |
-----END PGP SIGNATURE----- |