diff options
Diffstat (limited to 'ebuild-writing/functions/src_unpack')
8 files changed, 178 insertions, 378 deletions
diff --git a/ebuild-writing/functions/src_unpack/cvs-sources/text.xml b/ebuild-writing/functions/src_unpack/cvs-sources/text.xml deleted file mode 100644 index 2f24cc7..0000000 --- a/ebuild-writing/functions/src_unpack/cvs-sources/text.xml +++ /dev/null @@ -1,190 +0,0 @@ -<?xml version="1.0"?> -<guide self="ebuild-writing/functions/src_unpack/cvs-sources/"> -<chapter> -<title>CVS Sources</title> - -<body> -<p> -Rather than working with a source tarball, it is possible to use -upstream's CVS server directly. This can be useful when there is a -need to test unreleased snapshots on a regular basis. -</p> -</body> - -<section> -<title>Disadvantages of CVS Sources</title> -<body> - -<p> -Note that CVS ebuilds should <b>not</b> generally be added to the tree -for the following reasons: -</p> - -<ul> - <li> - Upstream CVS servers tend to be far less reliable than our mirroring - system. - </li> - <li> - CVS ebuilds create a very heavy server load <d/> not only is CVS not - mirrored, but allowing a CVS checkout is considerably more work for - a server than simply serving up a file via HTTP or FTP. - </li> - <li> - Many users who are behind strict firewalls cannot use CVS. - </li> -</ul> - -<p> -It is safer to make a snapshot instead. For example, vim snapshots are made using: -</p> - -<pre> -$ cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/vim export -r HEAD vim -</pre> -</body> -</section> - -<section> -<title>Disadvantages of CVS Live Sources</title> -<body> - -<p> -CVS ebuilds which work against CVS <c>HEAD</c> rather than a specific -date or revision are even worse candidates for tree inclusion: -</p> - -<ul> - <li> - You can never be sure whether upstream's CVS will actually - build at any given point; which will most likely cause QA issues. - </li> - <li> - It is extremely difficult to track down bugs when you cannot install - the same version of a package as the reporter. - </li> - <li> - Many upstream package maintainers tend to get upset if people aren't - using a specific released version. - </li> -</ul> - -</body> -</section> - -<section> -<title>Using CVS Sources</title> -<body> - -<note> -CVS ebuilds must be either with empty <c>KEYWORDS</c> or -package.masked (but <e>not</e> both). Empty <c>KEYWORDS</c> are -strongly preferred. This applies to "live" ebuilds (<c>-9999</c>) and -to ebuilds that extract a static revision but still use CVS for -fetching. -</note> - -<p> -To use a CVS source, <c>cvs.eclass</c> must be inherited, and then a -number of variables must be set. The following variables are often -useful: -</p> - -<table> - <tr> - <th>Variable</th> - <th>Purpose</th> - <th>Example</th> - </tr> - <tr> - <ti><c>ECVS_SERVER</c></ti> - <ti>Server and path</ti> - <ti><c>"cvs.sourceforge.net:/cvsroot/vim"</c></ti> - </tr> - <tr> - <ti><c>ECVS_MODULE</c></ti> - <ti>Module</ti> - <ti><c>"vim"</c></ti> - </tr> - <tr> - <ti><c>ECVS_BRANCH</c></ti> - <ti>Branch</ti> - <ti><c>"HEAD"</c></ti> - </tr> - <tr> - <ti><c>ECVS_AUTH</c></ti> - <ti>Auth method</ti> - <ti><c>"ext"</c></ti> - </tr> - <tr> - <ti><c>ECVS_USER</c></ti> - <ti>Username</ti> - <ti><c>"anoncvs"</c></ti> - </tr> - <tr> - <ti><c>ECVS_PASS</c></ti> - <ti>Password</ti> - <ti><c>""</c></ti> - </tr> - <tr> - <ti><c>ECVS_TOPDIR</c></ti> - <ti>Unpack location</ti> - <ti><c>"${DISTDIR}/cvs-src/${ECVS_MODULE}"</c></ti> - </tr> -</table> - -<p> -See the eclass itself for the full range of options. To perform the -actual checkout, use the <c>cvs_src_unpack</c> function. -</p> - -<p> -Here's a simple example, based upon the CVS options in vim.eclass: -</p> - -<codesample lang="ebuild"> -inherit cvs - -SRC_URI="" - -src_unpack() { - ECVS_SERVER="cvs.sourceforge.net:/cvsroot/vim" - ECVS_USER="anonymous" - ECVS_PASS="" - ECVS_AUTH="pserver" - if [[ $(get_major_version ) -ge 7 ]] ; then - ECVS_MODULE="vim7" - else - ECVS_MODULE="vim" - fi - ECVS_TOP_DIR="${DISTDIR}/cvs-src/${ECVS_MODULE}" - cvs_src_unpack -} -</codesample> - -<p> -Here's another approach, based upon the <c>emacs-cvs</c> ebuild, which -relies upon the default <c>src_unpack</c> provided in the eclass; this -approach is simpler but less flexible: -</p> - -<codesample lang="ebuild"> -inherit cvs - -ECVS_AUTH="ext" -CVS_RSH="ssh" -ECVS_SERVER="savannah.gnu.org:/cvsroot/emacs" -ECVS_MODULE="emacs" -ECVS_BRANCH="emacs-unicode-2" -ECVS_USER="anoncvs" -ECVS_PASS="" -ECVS_CVS_OPTIONS="-dP" - -# ...and so on. No src_unpack() is specified. -</codesample> - -</body> -</section> - -</chapter> -</guide> diff --git a/ebuild-writing/functions/src_unpack/deb-sources/text.xml b/ebuild-writing/functions/src_unpack/deb-sources/text.xml deleted file mode 100644 index bdbadb4..0000000 --- a/ebuild-writing/functions/src_unpack/deb-sources/text.xml +++ /dev/null @@ -1,12 +0,0 @@ -<?xml version="1.0"?> -<guide self="ebuild-writing/functions/src_unpack/deb-sources/"> -<chapter> -<title>Debian Sources</title> - -<body> -<todo> -from vapier: we dont have to 'handle' these because all debian packages have a source tarball ... the .deb format is pretty simple though, it's managed by the 'ar' utility from binutils. you can unpack a .deb by simply doing ar x blah.deb ... this will give you three files: debian-binary: plain text file which just contains version number of the .deb format control.tar.gz: a few files which control installing/verifying of package data.tar.gz: all the compiled files ... you could just extract it to / -</todo> -</body> -</chapter> -</guide> diff --git a/ebuild-writing/functions/src_unpack/other-formats/text.xml b/ebuild-writing/functions/src_unpack/other-formats/text.xml index 3647c80..891b322 100644 --- a/ebuild-writing/functions/src_unpack/other-formats/text.xml +++ b/ebuild-writing/functions/src_unpack/other-formats/text.xml @@ -1,7 +1,7 @@ -<?xml version="1.0"?> +<?xml version="1.0" encoding="UTF-8"?> <guide self="ebuild-writing/functions/src_unpack/other-formats/"> <chapter> -<title>Other Archive Formats</title> +<title>Other archive formats</title> <body> <p> @@ -11,7 +11,7 @@ Instructions for some of them are detailed below: </body> <section> -<title>Zip Files</title> +<title>Zip files</title> <body> <p> @@ -19,7 +19,7 @@ If a package is supplied as a .zip file, you should: </p> <ul> - <li><c>DEPEND</c> upon <c>app-arch/unzip</c></li> + <li><c>BDEPEND</c> upon <c>app-arch/unzip</c></li> <li>Use <c>unpack</c> as normal</li> </ul> @@ -27,7 +27,7 @@ If a package is supplied as a .zip file, you should: </section> <section> -<title>Shar Files</title> +<title>Shar files</title> <body> <p> If a package is supplied as a <c>.shar</c> file, you should repackage it locally @@ -39,7 +39,7 @@ done a release in at least ten years. </section> <section> -<title>RAR Files</title> +<title>RAR files</title> <body> <p> diff --git a/ebuild-writing/functions/src_unpack/rpm-sources/text.xml b/ebuild-writing/functions/src_unpack/rpm-sources/text.xml index dcf9113..0029c53 100644 --- a/ebuild-writing/functions/src_unpack/rpm-sources/text.xml +++ b/ebuild-writing/functions/src_unpack/rpm-sources/text.xml @@ -1,7 +1,7 @@ -<?xml version="1.0"?> +<?xml version="1.0" encoding="UTF-8"?> <guide self="ebuild-writing/functions/src_unpack/rpm-sources/"> <chapter> -<title>RPM Sources</title> +<title>RPM sources</title> <body> <p> @@ -19,16 +19,16 @@ that will unpack the RPM files. </p> <p> -If you do need to apply patches then override <c>src_unpack</c> in a +If you do need to call additional unpack functions then override <c>src_unpack</c> in a manner such as: </p> <codesample lang="ebuild"> -src_unpack () { - rpm_src_unpack ${A} - cd "${S}" +src_unpack() { + rpm_src_unpack ${A} + cd "${S}" - use ssl && epatch "${FILESDIR}/${PV}/${P}-ssl.patch" + use ssl && eapply "${FILESDIR}/${PV}/${P}-ssl.patch" } </codesample> @@ -40,7 +40,7 @@ format. </body> <section> -<title>Example RPM Handling</title> +<title>Example RPM handling</title> <body> <p> @@ -52,18 +52,20 @@ patches. The filename should be <c>suse-fetchmail-6.2.5.54.1.ebuild</c>. </p> <codesample lang="ebuild"> -# Copyright 1999-2005 Gentoo Foundation +# Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -# $Header: $ -inherit eutils versionator rpm +EAPI=7 + +inherit rpm -MY_PV=$(replace_version_separator 3 '-') +MY_PV=$(ver_rs 3 '-') MY_P=fetchmail-${MY_PV} -SRC_URI="http://suse.osuosl.org/suse/i386/9.2/suse/src/${MY_P}.src.rpm" DESCRIPTION="SuSE 9.2 Fetchmail Source Package" -HOMEPAGE="http://www.suse.com" +HOMEPAGE="https://www.suse.com" +SRC_URI="https://suse.osuosl.org/suse/i386/9.2/suse/src/${MY_P}.src.rpm" +S=${WORKDIR}/fetchmail-$(ver_cut 1-3) LICENSE="GPL-2 public-domain" SLOT="0" @@ -74,20 +76,22 @@ RESTRICT="mirror" # Need to test if the file can be unpacked with rpmoffset and cpio # If it can't then set: -#DEPEND="app-arch/rpm" +#BDEPEND="app-arch/rpm" # To force the use of rpmoffset and cpio instead of rpm2cpio from # app-arch/rpm, then set the following: #USE_RPMOFFSET_ONLY=1 -S=${WORKDIR}/fetchmail-$(get_version_component_range 1-3) - -src_unpack () { +src_unpack() { rpm_src_unpack ${A} - cd "${S}" - EPATCH_SOURCE="${WORKDIR}" EPATCH_SUFFIX="patch" \ - EPATCH_FORCE="yes" epatch +} + +src_prepare() { + for i in "${WORKDIR}"/*.patch ; do + eapply "${i}" + done + eapply_user } </codesample> diff --git a/ebuild-writing/functions/src_unpack/svn-sources/text.xml b/ebuild-writing/functions/src_unpack/svn-sources/text.xml deleted file mode 100644 index e436c97..0000000 --- a/ebuild-writing/functions/src_unpack/svn-sources/text.xml +++ /dev/null @@ -1,116 +0,0 @@ -<?xml version="1.0"?> -<guide self="ebuild-writing/functions/src_unpack/svn-sources/"> -<chapter> -<title>Subversion Sources</title> - -<body> -<p> -As with CVS, an eclass exists for working directly with upstream -Subversion repositories. See <uri link="::eclass-reference/subversion.eclass/">subversion.eclass</uri> -for a full list of functions and variables. Also see -the <uri link="::ebuild-writing/functions/src_unpack/cvs-sources"/> -ection. -</p> -</body> - -<section> -<title>Disadvantages of Subversion Sources</title> -<body> - -<p> -Note that Subversion ebuilds should <b>not</b> generally be added to -the tree for much the same reasons that live CVS ebuilds should not (see -<uri link="::ebuild-writing/functions/src_unpack/cvs-sources#Disadvantages of CVS Sources"/>). -Indeed, there should be even less impetus to add a live Subversion ebuild than a live CVS ebuild, as -Subversion checkouts are roughly a factor of five larger than an -equivalent CVS checkout. -</p> - -<p> -It is safer (and better for the user) to make a snapshot instead. For -example, <c>gentoo-syntax</c> snapshots could be made using: -</p> - -<pre> -$ svn export svn://svn.berlios.de/svnroot/repos/gentoo-syntax -r HEAD gentoo-syntax -</pre> -</body> -</section> - -<section> -<title>Using Subversion Sources</title> -<body> - -<note> -Subversion ebuilds must be either with empty <c>KEYWORDS</c> or -package.masked (but <e>not</e> both). Empty <c>KEYWORDS</c> are -strongly preferred. This applies to "live" ebuilds (<c>-9999</c>) and -to ebuilds that extract a static revision but still use Subversion for -fetching. -</note> - -<p> -To use a Subversion source, <c>subversion.eclass</c> must be -inherited, and then at least <c>ESVN_REPO_URI</c> must be set. The -following variables are also noteworthy: -</p> - -<table> - <tr> - <th>Variable</th> - <th>Purpose</th> - <th>Example</th> - </tr> - <tr> - <ti><c>ESVN_REPO_URI</c></ti> - <ti>Server and path (http, https, svn)</ti> - <ti><c>"svn://svn.example.com/foobar/trunk"</c></ti> - </tr> - <tr> - <ti><c>ESVN_STORE_DIR</c></ti> - <ti>Unpack location</ti> - <ti><c>ESVN_STORE_DIR="${DISTDIR}/svn-src"</c></ti> - </tr> - <tr> - <ti><c>ESVN_PROJECT</c></ti> - <ti>Project name of ebuild</ti> - <ti><c>ESVN_PROJECT="${PN/-svn}"</c></ti> - </tr> - <tr> - <ti><c>ESVN_BOOTSTRAP</c></ti> - <ti>Bootstrap command or script</ti> - <ti><c>ESVN_BOOTSTRAP="autogen.sh"</c></ti> - </tr> - <tr> - <ti><c>ESVN_PATCHES</c></ti> - <ti>Patches to apply during bootstrap</ti> - <ti><c>ESVN_PATCHES="${FILESDIR}/*.patch"</c></ti> - </tr> -</table> - -<p> -See the eclass itself and <uri link="::eclass-reference/subversion.eclass/">subversion.eclass</uri> -for the full range of options. To perform the actual checkout, use -the <c>subversion_src_unpack</c> function, which calls -both <c>subversion_svn_fetch</c> and <c>subversion_bootstrap</c> -itself. -</p> - -<p> -Here is a simple example, based upon the Subversion options in -<c>litu-svn-20040902.ebuild</c>; this approach is sufficient for most -Subversion ebuilds: -</p> - -<codesample lang="ebuild"> -inherit subversion - -ESVN_REPO_URI="http://tao.uab.es/ion/svn/libtu/trunk" -ESVN_PROJECT="libtu-snapshot" -</codesample> - -</body> -</section> - -</chapter> -</guide> diff --git a/ebuild-writing/functions/src_unpack/text.xml b/ebuild-writing/functions/src_unpack/text.xml index 542b3fb..250d947 100644 --- a/ebuild-writing/functions/src_unpack/text.xml +++ b/ebuild-writing/functions/src_unpack/text.xml @@ -1,4 +1,4 @@ -<?xml version="1.0"?> +<?xml version="1.0" encoding="UTF-8"?> <guide self="ebuild-writing/functions/src_unpack/"> <chapter> <title>src_unpack</title> @@ -11,7 +11,7 @@ </tr> <tr> <th>Purpose</th> - <ti>Extract source packages and do any necessary patching or fixes.</ti> + <ti>Extract source packages.</ti> </tr> <tr> <th>Sandbox</th> @@ -33,9 +33,9 @@ <body> <codesample lang="ebuild"> src_unpack() { - if [ "${A}" != "" ]; then - unpack ${A} - fi + if [[ -n ${A} ]]; then + unpack ${A} + fi } </codesample> </body> @@ -44,26 +44,19 @@ src_unpack() { <section> <title>Sample <c>src_unpack</c></title> <body> + <codesample lang="ebuild"> src_unpack() { - unpack ${A} - cd "${S}" - - epatch "${FILESDIR}/${PV}/${P}-fix-bogosity.patch" - use pam && epatch "${FILESDIR}/${PV}/${P}-pam.patch" - - sed -i -e 's/"ispell"/"aspell"/' src/defaults.h || die "Sed failed!" + unpack ${P}.tar.xz + use foo && unpack ${P}-foo-extension.tar.xz } </codesample> -<note> -When using EAPI >=2, you should use the <uri link="::ebuild-writing/functions/src_prepare">src_prepare</uri> function to apply patches or alter any of the source files, instead of the src_unpack. -</note> </body> </section> <section> -<title>Unpacking Tarballs</title> +<title>Unpacking tarballs</title> <body> <p> The <c>unpack</c> function should be used to unpack tarballs, compressed @@ -80,7 +73,43 @@ usually simpler to avoid working with <c>${A}</c>. </section> <section> -<title><c>src_unpack</c> Actions</title> +<title>Known file formats</title> +<body> + +<p> +The <c>unpack</c> function recognizes the following file formats: +</p> + +<ul> + <li><c>*.tar</c></li> + <li> + <c>*.gz</c>, <c>*.Z</c>, + <c>*.tar.gz</c>, <c>*.tgz</c>, <c>*.tar.Z</c> + </li> + <li> + <c>*.bz2</c>, <c>*.bz</c>, + <c>*.tar.bz2</c>, <c>*.tbz2</c>, <c>*.tar.bz</c>, <c>*.tbz</c> + </li> + <li><c>*.lzma</c>, <c>*.tar.lzma</c></li> + <li><c>*.xz</c>, <c>*.tar.xz</c>, <c>*.txz</c></li> + <li><c>*.zip</c>, <c>*.ZIP</c>, <c>*.jar</c></li> + <li><c>*.a</c>, <c>*.deb</c></li> +</ul> + +<p> +In EAPI 6 and later, filename extensions are matched case-insensitively. +</p> + +<important> +Unless the utility needed for unpacking is in the system set, the ebuild must +specify the necessary build time dependency (<c>BDEPEND</c>) for it. +</important> + +</body> +</section> + +<section> +<title><c>src_unpack</c> actions</title> <body> <p> The following subsections cover different topics which often occur when writing @@ -93,10 +122,7 @@ The following subsections cover different topics which often occur when writing </chapter> -<include href="cvs-sources/"/> -<include href="svn-sources/"/> -<include href="tla-sources/"/> +<include href="vcs-sources/"/> <include href="rpm-sources/"/> -<include href="deb-sources/"/> <include href="other-formats/"/> </guide> diff --git a/ebuild-writing/functions/src_unpack/tla-sources/text.xml b/ebuild-writing/functions/src_unpack/tla-sources/text.xml deleted file mode 100644 index 97a8b40..0000000 --- a/ebuild-writing/functions/src_unpack/tla-sources/text.xml +++ /dev/null @@ -1,12 +0,0 @@ -<?xml version="1.0"?> -<guide self="ebuild-writing/functions/src_unpack/tla-sources/"> -<chapter> -<title>Arch Sources</title> - -<body> -<todo> -Anyone want to write this? You can probably mostly copy the CVS Sources and Subversion Sources chapters. -</todo> -</body> -</chapter> -</guide> diff --git a/ebuild-writing/functions/src_unpack/vcs-sources/text.xml b/ebuild-writing/functions/src_unpack/vcs-sources/text.xml new file mode 100644 index 0000000..68fbe91 --- /dev/null +++ b/ebuild-writing/functions/src_unpack/vcs-sources/text.xml @@ -0,0 +1,100 @@ +<?xml version="1.0" encoding="UTF-8"?> +<guide self="ebuild-writing/functions/src_unpack/vcs-sources/"> +<chapter> +<title>Version Control System (VCS) sources</title> +<body> + +<p> +Rather than working with a source tarball, it is possible to use upstream +source code repositories directly. This can be useful when there is a need to +test unreleased snapshots on a regular basis. A number of eclasses exists for +this purpose; see their documentation for a list of available functions and +variables. +</p> + +<ul> + <li><uri link="::eclass-reference/cvs.eclass/"/></li> + <li><uri link="::eclass-reference/darcs.eclass/"/></li> + <li><uri link="::eclass-reference/git-r3.eclass/"/></li> + <li><uri link="::eclass-reference/mercurial.eclass/"/></li> + <li><uri link="::eclass-reference/subversion.eclass/"/></li> +</ul> + +<note> +VCS ebuilds must be with empty <c>KEYWORDS</c> but <e>not</e> package.masked +(except if the mask is for an independent reason). Usually the <c>KEYWORDS</c> +line should be omitted altogether. This applies to "live" ebuilds (<c>-9999</c>) +and to ebuilds that extract a static revision but still use a version control +system for fetching. +</note> + +</body> + +<section> +<title>Disadvantages of VCS sources</title> +<body> + +<p> +Note that VCS ebuilds should <b>not</b> generally be added to the tree for the +following reasons: +</p> + +<ul> + <li> + Upstream VCS servers tend to be far less reliable than our mirroring + system. + </li> + <li> + VCS ebuilds create a very heavy server load <d/> not only are repositories + not mirrored, but fetching sources from them is considerably more work for + a server than simply serving up a file via HTTP or FTP. + </li> + <li> + Local copies of a repository are several times larger than a tarball of the + same sources, and tend to grow over time because they include the history. + </li> + <li> + Many users who are behind strict firewalls cannot use protocols like CVS. + </li> +</ul> + +<p> +It is safer (and better for the user) to make a snapshot instead. For example, +<c>app-editors/emacs</c> snapshots are made using: +</p> + +<pre> +$ git archive --prefix=emacs/ HEAD | xz > emacs-${PV}.tar.xz +</pre> + +</body> +</section> + +<section> +<title>Disadvantages of VCS live sources</title> +<body> + +<p> +VCS ebuilds that work against the latest head (or tip) rather than a specific +date or revision are even worse candidates for tree inclusion: +</p> + +<ul> + <li> + You can never be sure whether upstream's source will actually build at any + given point; which will most likely cause QA issues. + </li> + <li> + It is extremely difficult to track down bugs when you cannot install the + same version of a package as the reporter. + </li> + <li> + Many upstream package maintainers tend to get upset if people aren't using + a specific released version. + </li> +</ul> + +</body> +</section> +</chapter> +</guide> |