aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--skel.ebuild80
1 files changed, 29 insertions, 51 deletions
diff --git a/skel.ebuild b/skel.ebuild
index 319747c47..0114d8c26 100644
--- a/skel.ebuild
+++ b/skel.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# NOTE: The comments in this file are for instruction and documentation.
@@ -6,27 +6,16 @@
# remember to remove them before submitting or committing your ebuild. That
# doesn't mean you can't add your own comments though.
-# The 'Header' on the third line should just be left alone. When your ebuild
-# will be committed to cvs, the details on that line will be automatically
-# 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
+# inherit lists eclasses to inherit functions from. For example, an ebuild
+# that needs the eautoreconf function from autotools.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
+#inherit autotools
#
# eclasses tend to list descriptions of how to use their functions properly.
# take a look at /usr/portage/eclass/ for more examples.
@@ -35,7 +24,7 @@ inherit eutils
DESCRIPTION="This is a sample skeleton ebuild file"
# Homepage, not used by Portage directly but handy for developer reference
-HOMEPAGE="http://foo.example.org/"
+HOMEPAGE="https://foo.example.org/"
# Point to any required sources; these will be automatically downloaded by
# Portage.
@@ -57,7 +46,7 @@ LICENSE=""
# of each SLOT and remove everything else.
# Note that normal applications should use SLOT="0" if possible, since
# there should only be exactly one version installed at a time.
-# DO NOT USE SLOT=""! This tells Portage to disable SLOTs for this package.
+# Do not use SLOT="", because the SLOT variable must not be empty.
SLOT="0"
# Using KEYWORDS, we can record masking information *inside* an ebuild
@@ -65,22 +54,21 @@ SLOT="0"
# set the KEYWORDS variable for every ebuild so that it contains the names of
# all the architectures with which the ebuild works. All of the official
# architectures can be found in the arch.list file which is in
-# /usr/portage/profiles/. Usually you should just set this to "~x86". The ~
-# in front of the architecture indicates that the package is new and should be
-# considered unstable until testing proves its stability. So, if you've
-# confirmed that your ebuild works on x86 and ppc, you'd specify:
-# KEYWORDS="~x86 ~ppc"
+# /usr/portage/profiles/. Usually you should just set this to "~amd64".
+# The ~ in front of the architecture indicates that the package is new and
+# should be considered unstable until testing proves its stability. So, if
+# you've confirmed that your ebuild works on amd64 and ppc, you'd specify:
+# KEYWORDS="~amd64 ~ppc"
# Once packages go stable, the ~ prefix is removed.
# For binary packages, use -* and then list the archs the bin package
# exists for. If the package was for an x86 binary package, then
# KEYWORDS would be set like this: KEYWORDS="-* x86"
-# DO NOT USE KEYWORDS="*". This is deprecated and only for backward
-# compatibility reasons.
-KEYWORDS="~x86"
+# Do not use KEYWORDS="*"; this is not valid in an ebuild context.
+KEYWORDS="~amd64"
# Comprehensive list of any and all USE flags leveraged in the ebuild,
-# with the exception of any ARCH specific flags, i.e. "ppc", "sparc",
-# "x86" and "alpha". Not needed if the ebuild doesn't use any USE flags.
+# with some exceptions, e.g., ARCH specific flags like "amd64" or "ppc".
+# Not needed if the ebuild doesn't use any USE flags.
IUSE="gnome X"
# A space delimited list of portage features to restrict. man 5 ebuild
@@ -110,7 +98,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:
@@ -129,36 +116,31 @@ RDEPEND="${DEPEND}"
# --mandir=/usr/share/man || die
# Note the use of --infodir and --mandir, above. This is to make
# this package FHS 2.2-compliant. For more information, see
- # http://www.pathname.com/fhs/
+ # https://www.pathname.com/fhs/
#}
# 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
- # builds (especially on SMP systems). Try emake first. It might
- # not work for some packages, because some makefiles have bugs
- # related to parallelism, in these cases, use emake -j1 to limit
- # make to a single process. The -j1 is a visual clue to others
- # that the makefiles have bugs that have been worked around.
-
- #emake || die
+ # emake is a script that calls the standard GNU make with parallel
+ # building options for speedier builds (especially on SMP systems).
+ # Try emake first. It might not work for some packages, because
+ # some makefiles have bugs related to parallelism, in these cases,
+ # use emake -j1 to limit make to a single process. The -j1 is a
+ # visual clue to others that the makefiles have bugs that have been
+ # worked around.
+
+ #emake
#}
# 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
# understanding the install part of the Makefiles.
# This is the preferred way to install.
- #emake DESTDIR="${D}" install || die
+ #emake DESTDIR="${D}" install
# When you hit a failure with emake, do not just use make. It is
# better to fix the Makefiles to allow proper parallelization.
@@ -174,11 +156,7 @@ RDEPEND="${DEPEND}"
# mandir="${D}"/usr/share/man \
# infodir="${D}"/usr/share/info \
# libdir="${D}"/usr/$(get_libdir) \
- # install || die
+ # install
# Again, verify the Makefiles! We don't want anything falling
# outside of ${D}.
-
- # The portage shortcut to the above command is simply:
- #
- #einstall || die
#}