1 |
On 02/25/2015 05:55 PM, Ulrich Mueller wrote: |
2 |
>>>>>> On Wed, 25 Feb 2015, Julian Ospald wrote: |
3 |
> |
4 |
>> +<warning> |
5 |
>> +You must not rely on provided functions of implicitly inherited eclasses. |
6 |
> |
7 |
> Not sure if this can be stated as a general policy. For example, if |
8 |
> your ebuild inherits elisp.eclass then it is pointless to inherit also |
9 |
> elisp-common.eclass, because it is guaranteed (and documented) that |
10 |
> all the functions of the latter will also be available when inheriting |
11 |
> the former. |
12 |
> |
13 |
|
14 |
Yes, see blow. |
15 |
|
16 |
>> +As an example: if you use <c>epatch</c> in your ebuild, you <b>must</b> |
17 |
>> +inherit <c>eutils.eclass</c> directly, even if another eclass (like distutils-r1) |
18 |
>> +already inherits it. Exceptions to this policy must be discussed and documented. |
19 |
>> +</warning> |
20 |
> |
21 |
> Documented, maybe. But I don't want to discuss a feature of my |
22 |
> eclasses which is in place since more than a decade and works |
23 |
> flawlessly. |
24 |
> |
25 |
|
26 |
What wording do you suggest instead? |
27 |
Maybe "Exceptions to this policy are documented in the respective eclasses"? |