1 |
While it's may be a good idea to set EAPI inside filename and if we ever |
2 |
decide on this, consider different implementation. |
3 |
|
4 |
I really dislike idea of EAPI-suffixed extensions. It's easier for me |
5 |
(and I think for others too) to differentiate ebuilds between other |
6 |
files in directory when ebuild files have common suffix. We are people |
7 |
so we should simplify things that are not hidden under the hood, like |
8 |
this... |
9 |
|
10 |
This hack is just to solve portage problem which does not ignore .ebuild |
11 |
files which does not follow pkg-ver.ebuild syntax and suggested solution |
12 |
is not the only solution. Other possibilities are, which I like more: |
13 |
|
14 |
1. USE pkg-ver.<EAPI>-ebuild |
15 |
|
16 |
2. USE pkg-ver${EAPITAG}<EAPI>.ebuild |
17 |
Here ${EAPITAG} is string to simplify parsing <EAPI> from |
18 |
version. E.g. EAPITAG could be _eapi or EAPI or something |
19 |
else. |
20 |
|
21 |
Although second solution does not solve the problem with portage I like |
22 |
it more, as we all have habit to look at .ebuild suffix. But this is |
23 |
different problem. Once we define good NEW format for filename it's |
24 |
possible to decide on transition path which allows us to use eapi right |
25 |
now. E.g. start using this format only with .ebuild-ng suffix and after |
26 |
three years pass it's possible to rename all .ebuild-ng into .ebuild. |
27 |
|
28 |
|
29 |
And another idea which was already mentioned somewhere in this thread. I |
30 |
think .ebuild should be written only in BASH. Again if we ever decide to |
31 |
use ebuilds with different syntax we should use different suffix. |
32 |
|
33 |
-- |
34 |
Peter. |