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