diff options
-rw-r--r-- | skel.ebuild | 80 |
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 #} |