| 1 |
>>>>> On Fri, 29 Jan 2016, Dean Stephens wrote: |
| 2 |
|
| 3 |
>> Don't mention ancient EAPIs that are banned. |
| 4 |
> That is of debatable utility if overlay generalized, your patch |
| 5 |
> applies it overly generally. |
| 6 |
|
| 7 |
This is skel.ebuild in the gentoo repo, so the rules for the main tree |
| 8 |
apply. Overlay owners can maintain their own skel.ebuild if their |
| 9 |
rules are different. |
| 10 |
|
| 11 |
>> # The EAPI variable tells the ebuild format in use. |
| 12 |
>> -# Defaults to 0 if not specified. |
| 13 |
> Removing that note is silly: you are removing factually accurate |
| 14 |
> documentation in favor of literally nothing. While EAPI=0 is banned |
| 15 |
> from the tree EAPI still defaults to 0; though some QA tools might, |
| 16 |
> perhaps even should, issue a warning in that case. |
| 17 |
|
| 18 |
skel.ebuild is a skeleton for writing new ebuilds, which can only be |
| 19 |
EAPI 4 or later. So for new ebuilds, that note is not relevant any |
| 20 |
more. |
| 21 |
|
| 22 |
Generally, I believe that skel.ebuild should be kept concise. We have |
| 23 |
more extensive documentation (e.g. the devmanual) where such things |
| 24 |
can be mentioned. |
| 25 |
|
| 26 |
>> # It is suggested that you use the latest EAPI approved by the Council. |
| 27 |
>> # The PMS contains specifications for all EAPIs. Eclasses will test for this |
| 28 |
>> -# variable if they need to use EAPI > 0 features. |
| 29 |
>> -EAPI=5 |
| 30 |
>> +# variable if they need to use features that are not universal in all EAPIs. |
| 31 |
>> +EAPI=6 |
| 32 |
> Any such "universal" features are, by definition, part of a subset |
| 33 |
> of EAPI=0, calling such features "universal" is even arguably |
| 34 |
> misleading. |
| 35 |
|
| 36 |
They are common to EAPIs 0 to 6. Why would it be misleading to call |
| 37 |
them "universal in all EAPIs"? |
| 38 |
|
| 39 |
> Better to document it as "Eclasses will test this variable if they |
| 40 |
> require features specific to a given EAPI or subset of EAPIs, or if |
| 41 |
> they provide different functionality under different EAPIs." |
| 42 |
|
| 43 |
"Subset of EAPIs" would not be accurate, because the set of all EAPIs |
| 44 |
is a subset of itself. |
| 45 |
|
| 46 |
>> -# inherit lists eclasses to inherit functions from. Almost all ebuilds should |
| 47 |
>> -# inherit eutils, as a large amount of important functionality has been |
| 48 |
>> -# moved there. For example, the epatch call mentioned below wont work |
| 49 |
>> -# without the following line: |
| 50 |
>> +# inherit lists eclasses to inherit functions from. For example, an ebuild |
| 51 |
>> +# that needs the epatch function from eutils.eclass won't work without the |
| 52 |
>> +# following line: |
| 53 |
>> inherit eutils |
| 54 |
> Trivially inaccurate, in a way that could be read as endorsing poor |
| 55 |
> form, the ebuild would need a call to inherit which included eutils, |
| 56 |
> it would not necessarily be the only eclass inherited from by means |
| 57 |
> of that call. |
| 58 |
|
| 59 |
You have a point here, but note that the wording "wont work without |
| 60 |
the following line" was already there in the original version. |
| 61 |
|
| 62 |
> "For example, an ebuild that uses the epatch function from the eutils |
| 63 |
> eclass would, at a minimum, need to inherit eutils, as in the following |
| 64 |
> line:" |
| 65 |
|
| 66 |
Yeah, feel free to post a new patch on top of mine (which I had pushed |
| 67 |
already). |
| 68 |
|
| 69 |
Ulrich |
Archives