Browse Source

update skel files

master
Guillaume Castagnino 3 months ago
parent
commit
075b4ef182
Signed by: casta GPG Key ID: C47D4BFADB084424
  1. 170
      skel.ebuild
  2. 50
      skel.metadata.xml

170
skel.ebuild

@ -1,42 +1,46 @@
# Copyright 1999-2018 Gentoo Authors
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# $Id:$
# NOTE: The comments in this file are for instruction and documentation.
# NOTE: The comments in this file are for instruction and documentation.
# They're not meant to appear with your final, production ebuild. Please
# 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.
# 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 features that are not universal in all EAPIs.
# If an eclass doesn't support latest EAPI, use the previous EAPI instead.
EAPI=7
# 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 $(get_libdir) 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/eclasses/ for more examples.
# Eclasses tend to list descriptions of how to use their functions properly.
# Take a look at the eclass/ directory for more examples.
# Short one-line description of this package.
DESCRIPTION="This is a sample skeleton ebuild file"
# Homepage, not used by Portage directly but handy for developer reference
HOMEPAGE="http://foo.bar.com/"
HOMEPAGE="https://foo.example.org/"
# Point to any required sources; these will be automatically downloaded by
# Portage.
SRC_URI="ftp://foo.bar.com/${P}.tar.gz"
SRC_URI="ftp://foo.example.org/${P}.tar.gz"
# Source directory; the dir where the sources can be found (automatically
# unpacked) inside ${WORKDIR}. The default value for S is ${WORKDIR}/${P}
# If you don't need to change it, leave the S= line out of the ebuild
# to keep it tidy.
#S="${WORKDIR}/${P}"
# License of the package. This must match the name of file(s) in
# /usr/portage/licenses/. For complex license combination see the developer
# License of the package. This must match the name of file(s) in the
# licenses/ directory. For complex license combination see the developer
# docs on gentoo.org for details.
LICENSE=""
@ -50,58 +54,63 @@ 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
# instead of relying on an external package.mask file. Right now, you
# should 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 keywords.desc 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. Once
# packages go stable the ~ prefix is removed. So, if you've confirmed that
# your ebuild works on x86 and ppc, you'd specify: KEYWORDS="~x86 ~ppc"
# 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 the profiles/ directory. 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". This is a required variable. If the ebuild doesn't
# use any USE flags, set to "".
IUSE="X gnome"
# 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
# for details. Usually not needed.
#RESTRICT="nostrip"
#RESTRICT="strip"
# Build-time dependencies, such as
# ssl? ( >=dev-libs/openssl-0.9.6b )
# >=dev-lang/perl-5.6.1-r1
# Run-time dependencies. Must be defined to whatever this depends on to run.
# Example:
# ssl? ( >=dev-libs/openssl-1.0.2q:0= )
# >=dev-lang/perl-5.24.3-r1
# It is advisable to use the >= syntax show above, to reflect what you
# had installed on your system when you tested the package. Then
# other users hopefully won't be caught without the right version of
# a dependency.
DEPEND=""
# Run-time dependencies, same as DEPEND if RDEPEND isn't defined:
#RDEPEND=""
# Source directory; the dir where the sources can be found (automatically
# unpacked) inside ${WORKDIR}. The default value for S is ${WORKDIR}/${P}
# If you don't need to change it, leave the S= line out of the ebuild
# to keep it tidy.
S=${WORKDIR}/${P}
# Build-time dependencies that need to be binary compatible with the system
# being built (CHOST). These include libraries that we link against.
# The below is valid if the same run-time depends are required to compile.
#DEPEND="${RDEPEND}"
# Build-time dependencies that are executed during the emerge process, and
# only need to be present in the native build system (CBUILD). Example:
#BDEPEND="virtual/pkgconfig"
src_compile() {
# The following src_configure function is implemented as default by portage, so
# you only need to call it if you need a different behaviour.
#src_configure() {
# Most open-source packages use GNU autoconf for configuration.
# The quickest (and preferred) way of running configure is:
econf || die "econf failed"
# The default, quickest (and preferred) way of running configure is:
#econf
#
# You could use something similar to the following lines to
# configure your package before compilation. The "|| die" portion
@ -113,43 +122,50 @@ src_compile() {
# --host=${CHOST} \
# --prefix=/usr \
# --infodir=/usr/share/info \
# --mandir=/usr/share/man || die "./configure failed"
# --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/
# 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 failed"
}
src_install() {
# https://wiki.linuxfoundation.org/lsb/fhs
#}
# The following src_compile function is implemented as default by portage, so
# you only need to call it, if you need different behaviour.
#src_compile() {
# 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.
#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.
make 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.
# If you fail with that, use "emake -j1", it's still better than make.
# For Makefiles that don't make proper use of DESTDIR, setting
# prefix is often an alternative. However if you do this, then
# you also need to specify mandir and infodir, since they were
# passed to ./configure as absolute paths (overriding the prefix
# setting).
#make \
# prefix=${D}/usr \
# mandir=${D}/usr/share/man \
# infodir=${D}/usr/share/info \
# libdir=${D}/usr/$(get_libdir) \
# install || die
#emake \
# prefix="${D}"/usr \
# mandir="${D}"/usr/share/man \
# infodir="${D}"/usr/share/info \
# libdir="${D}"/usr/$(get_libdir) \
# 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
}
#}

50
skel.metadata.xml

@ -1,24 +1,38 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<!--
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<!--
This is the example metadata file.
The root element of this file is <pkgmetadata>. Within this element a
number of subelements are allowed, the most common being maintainer.
This is the example metadata file.
The root element of this file is <pkgmetadata>. Within this element a
number of subelements are allowed: herd, maintainer, and
longdescription. herd is a required subelement.
For a full description look at:
https://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/
For a full description look at:
http://www.gentoo.org/proj/en/metastructure/herds/
Before committing, please remove the comments from this file. They are
not relevant for general metadata.xml files.
Before committing, please remove the comments from this file. They are
not relevant for general metadata.xml files.
-->
<pkgmetadata>
<herd>no-herd</herd>
<maintainer>
<email>@gentoo.org</email>
<!-- <description>Description of the maintainership</description> -->
</maintainer>
<!-- <longdescription>Long description of the package</longdescription> -->
<maintainer type="person">
<email>exampledev@gentoo.org</email>
<description>Primary maintainer</description>
</maintainer>
<maintainer type="project">
<email>exampleproject@gentoo.org</email>
<name>Gentoo Example Project</name>
</maintainer>
<longdescription>
Long description of the package. Note that long description should be long.
This section doesn't have to exist, if it doesn't differ from ebuild's
DESCRIPTION.
Using either spaces or tabs to indent is allowed. However mixing both in
a single metadata.xml file is not.
</longdescription>
<use>
<flag name="aspell">Uses <pkg>app-text/aspell</pkg> for spell checking.
Requires an installed dictionary from <cat>app-dicts</cat></flag>
<flag name="flag">Description of how USE='flag' affects this package</flag>
<flag name="userland_GNU">Description of how USERLAND='GNU' affects this
package</flag>
</use>
</pkgmetadata>

Loading…
Cancel
Save