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