1 |
> Yes. And here another point should be brought up. This proposal should |
2 |
> be wider and consider similar changes for the most common used |
3 |
> operations on all phases. |
4 |
|
5 |
And in fact, the most common used operations on all phases are |
6 |
already covered: Namely, this is the default implementation of the phase. |
7 |
Any change from this is not so common and should therefore be based on |
8 |
writing the function. Saving here some characters for typing the |
9 |
function header means to save at the wrong place by making everything |
10 |
less readable and less maintainable. (Moreover, in most cases, |
11 |
this would not even save some characters, because the variable |
12 |
names would have to be much longer...) |
13 |
|
14 |
Actually, too many variables with a predefined meaning are used in |
15 |
ebuilds already now. The original intention of ebuilds was that - |
16 |
in contrast to .spec-files or other stuff which are some sort of |
17 |
extended database - it should be simple pure shell code which everybody |
18 |
can easily read or write without filling in magic data. |
19 |
Things like WANT_AUTOMAKE=1.8 already violate this rule, but it seems |
20 |
hard to avoid it here, because IIRC there is no "src_depend()" function |
21 |
where the calculation of the dependencies could be done in a consistent |
22 |
manner. But the rule should not be violated without any serious need: |
23 |
If ebuilds consist only in setting magic variables, you can use .spec |
24 |
as well. |