[gentoo-dev] Update skel.ebuild for EAPI 6

[gentoo-dev] Update skel.ebuild for EAPI 6

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]

See patch included below. I have kept the changes at the bare minimum
necessary to update this for EAPI 6. A major rewrite of the file may
be considered later.

Ulrich


From 599ad94e1a2f2961e5ef0175bea01cd1b2eb96f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Mon, 25 Jan 2016 20:01:26 +0100
Subject: [PATCH] skel.ebuild: Update for EAPI 6.

Put less emphasis on eutils and epatch; they will be used less often
with eapply being available in EAPI 6.

Don't mention ancient EAPIs that are banned.

Don't mention einstall since it is banned.
---
 skel.ebuild | 27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/skel.ebuild b/skel.ebuild
index d907f9b..0483b53 100644
--- a/skel.ebuild
+++ b/skel.ebuild
@@ -12,22 +12,15 @@
 # generated to contain the correct data.
 
 # The EAPI variable tells the ebuild format in use.
-# Defaults to 0 if not specified.
 # 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
 
-# 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
-# A well-used example of an eclass function that needs eutils is epatch. If
-# your source needs patches applied, it's suggested to put your patch in the
-# 'files' directory and use:
-#
-#   epatch "${FILESDIR}"/patch-name-here
 #
 # eclasses tend to list descriptions of how to use their functions properly.
 # take a look at /usr/portage/eclass/ for more examples.
@@ -111,7 +104,6 @@ RDEPEND="${DEPEND}"
 
 # The following src_configure function is implemented as default by portage, so
 # you only need to call it if you need a different behaviour.
-# This function is available only in EAPI 2 and later.
 #src_configure() {
 	# Most open-source packages use GNU autoconf for configuration.
 	# The default, quickest (and preferred) way of running configure is:
@@ -135,9 +127,6 @@ RDEPEND="${DEPEND}"
 
 # The following src_compile function is implemented as default by portage, so
 # you only need to call it, if you need different behaviour.
-# For EAPI < 2 src_compile runs also commands currently present in
-# src_configure. Thus, if you're using an older EAPI, you need to copy them
-# to your src_compile and drop the src_configure function.
 #src_compile() {
 	# emake (previously known as pmake) is a script that calls the
 	# standard GNU make with parallel building options for speedier
@@ -152,8 +141,6 @@ RDEPEND="${DEPEND}"
 
 # The following src_install function is implemented as default by portage, so
 # you only need to call it, if you need different behaviour.
-# For EAPI < 4 src_install is just returing true, so you need to always specify
-# this function in older EAPIs.
 #src_install() {
 	# You must *personally verify* that this trick doesn't install
 	# anything outside of DESTDIR; do this by reading and
@@ -178,8 +165,4 @@ RDEPEND="${DEPEND}"
 	#	install
 	# Again, verify the Makefiles!  We don't want anything falling
 	# outside of ${D}.
-
-	# The portage shortcut to the above command is simply:
-	#
-	#einstall
 #}
-- 
2.7.0

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Update skel.ebuild for EAPI 6

[Dean Stephens]

On 01/25/16 14:18, Ulrich Mueller wrote:
> See patch included below. I have kept the changes at the bare minimum
> necessary to update this for EAPI 6. A major rewrite of the file may
> be considered later.
> 
> Ulrich
> 
> 
> From 599ad94e1a2f2961e5ef0175bea01cd1b2eb96f7 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
> Date: Mon, 25 Jan 2016 20:01:26 +0100
> Subject: [PATCH] skel.ebuild: Update for EAPI 6.
> 
> Put less emphasis on eutils and epatch; they will be used less often
> with eapply being available in EAPI 6.
> 
> Don't mention ancient EAPIs that are banned.
That is of debatable utility if overlay generalized, your patch applies
it overly generally.
> 
> Don't mention einstall since it is banned.
> ---
>  skel.ebuild | 27 +++++----------------------
>  1 file changed, 5 insertions(+), 22 deletions(-)
> 
> diff --git a/skel.ebuild b/skel.ebuild
> index d907f9b..0483b53 100644
> --- a/skel.ebuild
> +++ b/skel.ebuild
> @@ -12,22 +12,15 @@
>  # generated to contain the correct data.
>  
>  # 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.
>  # 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.
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."
>  
> -# 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.
"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:"
> -# A well-used example of an eclass function that needs eutils is epatch. If
> -# your source needs patches applied, it's suggested to put your patch in the
> -# 'files' directory and use:
> -#
> -#   epatch "${FILESDIR}"/patch-name-here
>  #
>  # eclasses tend to list descriptions of how to use their functions properly.
>  # take a look at /usr/portage/eclass/ for more examples.
> @@ -111,7 +104,6 @@ RDEPEND="${DEPEND}"
>  
>  # The following src_configure function is implemented as default by portage, so
>  # you only need to call it if you need a different behaviour.
> -# This function is available only in EAPI 2 and later.
>  #src_configure() {
>  	# Most open-source packages use GNU autoconf for configuration.
>  	# The default, quickest (and preferred) way of running configure is:
> @@ -135,9 +127,6 @@ RDEPEND="${DEPEND}"
>  
>  # The following src_compile function is implemented as default by portage, so
>  # you only need to call it, if you need different behaviour.
> -# For EAPI < 2 src_compile runs also commands currently present in
> -# src_configure. Thus, if you're using an older EAPI, you need to copy them
> -# to your src_compile and drop the src_configure function.
>  #src_compile() {
>  	# emake (previously known as pmake) is a script that calls the
>  	# standard GNU make with parallel building options for speedier
> @@ -152,8 +141,6 @@ RDEPEND="${DEPEND}"
>  
>  # The following src_install function is implemented as default by portage, so
>  # you only need to call it, if you need different behaviour.
> -# For EAPI < 4 src_install is just returing true, so you need to always specify
> -# this function in older EAPIs.
>  #src_install() {
>  	# You must *personally verify* that this trick doesn't install
>  	# anything outside of DESTDIR; do this by reading and
> @@ -178,8 +165,4 @@ RDEPEND="${DEPEND}"
>  	#	install
>  	# Again, verify the Makefiles!  We don't want anything falling
>  	# outside of ${D}.
> -
> -	# The portage shortcut to the above command is simply:
> -	#
> -	#einstall
>  #}
> 

Re: [gentoo-dev] Update skel.ebuild for EAPI 6

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2937 bytes --]

>>>>> 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 #2: Type: application/pgp-signature, Size: 490 bytes --]