[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Update skel.ebuild for EAPI 6
From:       Ulrich Mueller <ulm () gentoo ! org>
Date:       2016-01-30 9:16:46
Message-ID: 22188.32638.411808.841987 () a1i15 ! kph ! uni-mainz ! de
[Download RAW message or body]


>>>>> On Fri, 29 Jan 2016, Dean Stephens wrote:

>> Don't mention ancient EAPIs that are banned.
> That is of debatable utility if overlay generalized, your patch
> applies it overly generally.

This is skel.ebuild in the gentoo repo, so the rules for the main tree
apply. Overlay owners can maintain their own skel.ebuild if their
rules are different.

>>  # The EAPI variable tells the ebuild format in use.
>> -# Defaults to 0 if not specified.
> Removing that note is silly: you are removing factually accurate
> documentation in favor of literally nothing. While EAPI=0 is banned
> from the tree EAPI still defaults to 0; though some QA tools might,
> perhaps even should, issue a warning in that case.

skel.ebuild is a skeleton for writing new ebuilds, which can only be
EAPI 4 or later. So for new ebuilds, that note is not relevant any
more.

Generally, I believe that skel.ebuild should be kept concise. We have
more extensive documentation (e.g. the devmanual) where such things
can be mentioned.

>>  # It is suggested that you use the latest EAPI approved by the Council.
>>  # The PMS contains specifications for all EAPIs. Eclasses will test for this
>> -# variable if they need to use EAPI > 0 features.
>> -EAPI=5
>> +# variable if they need to use features that are not universal in all EAPIs.
>> +EAPI=6
> Any such "universal" features are, by definition, part of a subset
> of EAPI=0, calling such features "universal" is even arguably
> misleading.

They are common to EAPIs 0 to 6. Why would it be misleading to call
them "universal in all EAPIs"?

> Better to document it as "Eclasses will test this variable if they
> require features specific to a given EAPI or subset of EAPIs, or if
> they provide different functionality under different EAPIs."

"Subset of EAPIs" would not be accurate, because the set of all EAPIs
is a subset of itself.

>> -# inherit lists eclasses to inherit functions from. Almost all ebuilds should
>> -# inherit eutils, as a large amount of important functionality has been
>> -# moved there. For example, the epatch call mentioned below wont work
>> -# without the following line:
>> +# inherit lists eclasses to inherit functions from. For example, an ebuild
>> +# that needs the epatch function from eutils.eclass won't work without the
>> +# following line:
>> inherit eutils
> Trivially inaccurate, in a way that could be read as endorsing poor
> form, the ebuild would need a call to inherit which included eutils,
> it would not necessarily be the only eclass inherited from by means
> of that call.

You have a point here, but note that the wording "wont work without
the following line" was already there in the original version.

> "For example, an ebuild that uses the epatch function from the eutils
> eclass would, at a minimum, need to inherit eutils, as in the following
> line:"

Yeah, feel free to post a new patch on top of mine (which I had pushed
already).

Ulrich

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]