Swapped out PKGBUILD.8 for PKGBUILD.5 from Dan McGee - original PKGBUILD.8 had too many Frugal specific changes.
This commit is contained in:
parent
7d63ecfac6
commit
c32a7fcc85
2 changed files with 286 additions and 460 deletions
286
doc/PKGBUILD.5
Normal file
286
doc/PKGBUILD.5
Normal file
|
@ -0,0 +1,286 @@
|
||||||
|
." the string declarations are a start to try and make distro independent
|
||||||
|
.ds DS Arch Linux
|
||||||
|
.ds PB PKGBUILD
|
||||||
|
.ds VR 3.0.0
|
||||||
|
.TH PKGBUILD 5 "Feb 06, 2007" "PKGBUILD version \*(VR" "\*(DS Files"
|
||||||
|
.SH NAME
|
||||||
|
PKGBUILD \- \*(DS package build description file
|
||||||
|
.SH DESCRIPTION
|
||||||
|
This manual page is meant to describe general rules about PKGBUILDs. Once
|
||||||
|
a PKGBUILD is written, the actual package is built using \fBmakepkg\fR and
|
||||||
|
installed with \fBpacman\fR.
|
||||||
|
|
||||||
|
\fBNOTE:\fR If you have a local copy of the Arch Build System (ABS) tree
|
||||||
|
on your computer, you can copy the PKGBUILD.proto file to your new package
|
||||||
|
build directory and edit it from there. To acquire/sync the ABS tree, use
|
||||||
|
the \fBabs\fR script included with pacman/makepkg.
|
||||||
|
|
||||||
|
.SS Quick PKGBUILD Explanation
|
||||||
|
For an example of a PKGBUILD, see the \fBEXAMPLE\fR section.
|
||||||
|
|
||||||
|
\fIpkgname\fR defines the package name. It should not contain any uppercase
|
||||||
|
letters. \fIpkgversion\fR defines the actual package version as given by the
|
||||||
|
developers of the package. No dashes are allowed. \fIpkgrel\fR allows for
|
||||||
|
\*(DS-specific changes to the package or corrections to a PKGBUILD
|
||||||
|
without an upstream version change. The value should be an integer.
|
||||||
|
\fIpkgdesc\fR is a short one-line description for the package, usually taken
|
||||||
|
from the project's homepage or manpage. It is preferable to keep the length to
|
||||||
|
one line for displaying during searches. These four variables are required in
|
||||||
|
every PKGBUILD. \fIurl\fR is also highly recommended so users can find more
|
||||||
|
information on the package if needed.
|
||||||
|
|
||||||
|
\fIdepends\fR and \fImakedepends\fR are bash arrays which define the
|
||||||
|
dependencies of the package. Packages listed in \fImakedepends\fR are required
|
||||||
|
only for building the package, and not for runtime. \fIdepends\fR is used to
|
||||||
|
list runtime depends. To build the package using \fBmakepkg\fR, ALL dependencies
|
||||||
|
must be satisfied. For \fBpacman\fR to install the package, all runtime depends
|
||||||
|
must be satisfied.
|
||||||
|
|
||||||
|
The \fIbackup\fR array specifies files that should be treated specially
|
||||||
|
when removing or upgrading packages. See \fBHANDLING CONFIG FILES\fR in
|
||||||
|
the \fIpacman\fR manpage for more information on this.
|
||||||
|
|
||||||
|
The \fIsource()\fR array tells makepkg which files to download or extract before
|
||||||
|
compiling begins. The \fImd5sums()\fR array provides md5sums for each of these
|
||||||
|
files. These are used to validate the integrity of the source files.
|
||||||
|
|
||||||
|
The \fIbuild\fR function is what actually does the work of putting the package
|
||||||
|
together. Sometimes this is as simple as a configure, make, make install (to
|
||||||
|
$startdir/pkg). However, some customizations are often needed during the build
|
||||||
|
process.
|
||||||
|
|
||||||
|
Once your PKGBUILD is created, you can run \fBmakepkg\fR from the build
|
||||||
|
directory. \fBmakepkg\fR will check dependencies and look for the source files
|
||||||
|
required to build. If some are missing it will attempt to download them,
|
||||||
|
provided there is a fully-qualified URL in the \fIsource()\fR array.
|
||||||
|
|
||||||
|
.SS Install/Upgrade/Remove Scripting
|
||||||
|
Pacman has the ability to store and execute a package-specific script when it
|
||||||
|
installs, removes, or upgrades a package. This allows a package to "configure
|
||||||
|
itself" after installation and do the opposite right before it is removed.
|
||||||
|
|
||||||
|
The exact time the script is run varies with each operation:
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B pre_install
|
||||||
|
script is run right before files are extracted.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B post_install
|
||||||
|
script is run right after files are extracted.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B pre_upgrade
|
||||||
|
script is run right before files are extracted.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B post_upgrade
|
||||||
|
script is run after files are extracted.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B pre_remove
|
||||||
|
script is run right before files are removed.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B post_remove
|
||||||
|
script is run right after files are removed.
|
||||||
|
|
||||||
|
.P
|
||||||
|
To use this feature, just create a file (eg, pkgname.install) and put it in
|
||||||
|
the same directory as the PKGBUILD script. Then use the \fIinstall\fR
|
||||||
|
directive:
|
||||||
|
|
||||||
|
install=pkgname.install
|
||||||
|
|
||||||
|
The install script does not need to be specified in the \fIsource\fR array.
|
||||||
|
A template install file is available in your ABS tree (/var/abs/install.proto).
|
||||||
|
|
||||||
|
.SH OPTIONS AND DIRECTIVES
|
||||||
|
.TP
|
||||||
|
.B pkgname
|
||||||
|
The name of the package. This has be a unix-friendly name as it will be
|
||||||
|
used in the package filename.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B pkgver
|
||||||
|
This is the version of the software as released from the author (eg, 2.7.1).
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B pkgrel
|
||||||
|
This is the release number specific to \*(DS's release. This allows package
|
||||||
|
maintainers to make updates to the package's configure flags, for example.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B pkgdesc
|
||||||
|
This should be a brief description of the package and its functionality.
|
||||||
|
|
||||||
|
." Is this applicable below?
|
||||||
|
.TP
|
||||||
|
.B pkgdesc_localized \fI(array)\fR
|
||||||
|
Array of the localized package descriptions. The format is the following:
|
||||||
|
pkgdesc_localized=('xx_YY foo' 'xx_YY bar')
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B url
|
||||||
|
This field contains an optional URL that is associated with the piece of
|
||||||
|
software being packaged. This is typically the project's website.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B license \fI(array)\fR
|
||||||
|
This field specifies the license(s) that apply to the package. Commonly-used
|
||||||
|
licenses are typically found in \fI/usr/share/licenses/common\fR. If you
|
||||||
|
see the package's license there, simply reference it in the license field
|
||||||
|
(eg, \fBlicense="GPL"\fR). If the package provides a license not found in
|
||||||
|
\fI/usr/share/licenses/common\fR, then you should include the license in
|
||||||
|
the package itself and set \fBlicense="custom"\fR or
|
||||||
|
\fBlicense="custom:LicenseName"\fR. The license itself should be placed in a
|
||||||
|
directory called \fI$startdir/pkg/usr/share/licenses/$pkgname\fR. If multiple
|
||||||
|
licenses are applied, use the array form: \fBlicenses=('GPL' 'FDL')\fR
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B install
|
||||||
|
Specifies a special install script that is to be included in the package.
|
||||||
|
This file should reside in the same directory as the PKGBUILD, and will be
|
||||||
|
copied into the package by makepkg. It does not need to be included in the
|
||||||
|
\fIsource\fR array. (eg, install=pkgname.install)
|
||||||
|
|
||||||
|
." Is this applicable below?
|
||||||
|
.TP
|
||||||
|
.B up2date
|
||||||
|
This directive should contain a command that prints the current upstream stable
|
||||||
|
version of the project.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B source \fI(array)\fR
|
||||||
|
The \fIsource\fR line is an array of source files required to build the
|
||||||
|
package. Source files must reside in the same directory as the PKGBUILD
|
||||||
|
file, unless they have a fully-qualified URL.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B md5sums \fI(array)\fR
|
||||||
|
If this field is present, it should contain an MD5 hash for every source file
|
||||||
|
specified in the \fIsource\fR array (in the same order). \fImakepkg\fR will use
|
||||||
|
this to verify source file integrity during subsequent builds. To easily
|
||||||
|
generate md5sums, first build using the PKGBUILD then run
|
||||||
|
\fBmakepkg -g >>PKGBUILD\fR. Then you can edit the PKGBUILD and move the
|
||||||
|
\fImd5sums\fR line from the bottom to an appropriate location.
|
||||||
|
|
||||||
|
." Is this applicable below?
|
||||||
|
.TP
|
||||||
|
.B signatures \fI(array)\fR
|
||||||
|
If this field is present, it should contain an array of gpg signatures required
|
||||||
|
to validate the source files. Where there is no signature available just leave
|
||||||
|
it empty, like:
|
||||||
|
|
||||||
|
signatures=(${source[0]}.asc '')
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B groups \fI(array)\fR
|
||||||
|
This is an array of symbolic names that represent groups of packages, allowing
|
||||||
|
you to install multiple packages by requesting a single target. For example,
|
||||||
|
one could install all KDE packages by installing the 'kde' group.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B archs \fI(array)\fR
|
||||||
|
This array defines on which architectures the given package is available.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B backup \fI(array)\fR
|
||||||
|
A space-delimited array of filenames (without a preceding slash). The
|
||||||
|
\fIbackup\fR line will be propagated to the package meta-info file for
|
||||||
|
pacman. This will designate all files listed there to be backed up if this
|
||||||
|
package is ever removed from a system. See \fBHANDLING CONFIG FILES\fR in
|
||||||
|
the \fIpacman\fR manpage for more information.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B depends \fI(array)\fR
|
||||||
|
An array of packages that this package depends on to build and run. Packages
|
||||||
|
in this list should be surrounded with single quotes and contain at least the
|
||||||
|
package name. They can also include a version requirement of the form
|
||||||
|
\fBname<>version\fR, where <> is one of these three comparisons:
|
||||||
|
\fB>=\fR (greater than equal to), \fB<=\fR (less than or equal to), or
|
||||||
|
\fB=\fR (equal to).
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B makedepends \fI(array)\fR
|
||||||
|
An array of packages that this package depends on to build, but not at runtime.
|
||||||
|
Packages in this list should follow the same format as \fIdepends\fR.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B conflicts \fI(array)\fR
|
||||||
|
An array of packages that will conflict with this package (ie, they cannot both
|
||||||
|
be installed at the same time). This directive follows the same format as
|
||||||
|
\fIdepends\fR except you cannot specify versions.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B provides \fI(array)\fR
|
||||||
|
An array of "virtual provisions" that this package provides. This allows a
|
||||||
|
package to provide dependencies other than its own package name. For example,
|
||||||
|
the kernel26beyond package can each provide 'kernel26' which allows packages
|
||||||
|
to simply depend on 'kernel26' rather than "kernel26 OR kernel26beyond".
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B replaces \fI(array)\fR
|
||||||
|
This is an array of packages that this package should replace, and can be used
|
||||||
|
to handle renamed/combined packages. For example, if the j2re package gets
|
||||||
|
renamed to jre, then subsequent 'pacman -Syu' calls will not pick up the
|
||||||
|
upgrade, due to the differing package names. \fIreplaces\fR handles this.
|
||||||
|
|
||||||
|
.TP
|
||||||
|
.B options \fI(array)\fR
|
||||||
|
This array allows you to override some of makepkg's default behaviour
|
||||||
|
when building packages. To set an option, just include the option name
|
||||||
|
in the \fBoptions\fR array.
|
||||||
|
.RS
|
||||||
|
.TP
|
||||||
|
.B nostrip
|
||||||
|
don't strip binaries/libraries.
|
||||||
|
.TP
|
||||||
|
.B keepdocs
|
||||||
|
keep /usr/share/doc and /usr/share/info directories.
|
||||||
|
.TP
|
||||||
|
.B force
|
||||||
|
force the package to be upgraded by --sysupgrade, even if it's an older version.
|
||||||
|
.RE
|
||||||
|
|
||||||
|
.SH EXAMPLE
|
||||||
|
The following is an example PKGBUILD for the 'modutils' package. For more
|
||||||
|
examples, look through the ABS tree.
|
||||||
|
|
||||||
|
.nf
|
||||||
|
# Maintainer: John Doe <johndoe@archlinux.org>
|
||||||
|
pkgname=modutils
|
||||||
|
pkgver=2.4.25
|
||||||
|
pkgrel=1
|
||||||
|
pkgdesc="Utilities for inserting modules in the linux kernel"
|
||||||
|
url="http://www.kernel.org"
|
||||||
|
makedepends=('bash' 'mawk')
|
||||||
|
depends=('glibc' 'zlib')
|
||||||
|
backup=(etc/modules.conf)
|
||||||
|
source=(ftp://ftp.kernel.org/pub/linux/utils/kernel/$pkgname/v2.4/$pkgname-$pkgver.tar.bz2 \\
|
||||||
|
modules.conf)
|
||||||
|
md5sums=('2c0cca3ef6330a187c6ef4fe41ecaa4d' \\
|
||||||
|
'35175bee593a7cc7d6205584a94d8625')
|
||||||
|
|
||||||
|
build() {
|
||||||
|
cd $startdir/src/$pkgname-$pkgver
|
||||||
|
./configure --prefix=/usr --enable-insmod-static
|
||||||
|
make || return 1
|
||||||
|
make prefix=$startdir/pkg/usr install
|
||||||
|
mv $startdir/pkg/usr/sbin $startdir/pkg
|
||||||
|
mkdir -p $startdir/pkg/etc
|
||||||
|
cp ../modules.conf $startdir/pkg/etc
|
||||||
|
}
|
||||||
|
.fi
|
||||||
|
|
||||||
|
.SH SEE ALSO
|
||||||
|
.BR makepkg (8),
|
||||||
|
.BR pacman (8)
|
||||||
|
|
||||||
|
See the Arch Linux website at <http://www.archlinux.org> for more current
|
||||||
|
information on the distribution, and
|
||||||
|
<http://wiki.archlinux.org/index.php/Arch_Packaging_Standards> for
|
||||||
|
recommendations on packaging standards.
|
||||||
|
.SH AUTHORS
|
||||||
|
Judd Vinet <jvinet@zeroflux.org>
|
||||||
|
and the Frugalware developers <frugalware-devel@frugalware.org>
|
460
doc/PKGBUILD.8
460
doc/PKGBUILD.8
|
@ -1,460 +0,0 @@
|
||||||
.TH PKGBUILD 8 "June 13, 2006" "Archlinux Developer Manual" ""
|
|
||||||
.SH NAME
|
|
||||||
PKGBUILD \- Archlinux package builder descriptor
|
|
||||||
.SH DESCRIPTION
|
|
||||||
This manual page is meant to describe general rules about PKGBUILDs. If
|
|
||||||
you're interested in the package builder \fBmakepkg\fP itself, then see its
|
|
||||||
manual page, not this one.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.TP
|
|
||||||
.SH PKGBUILD Example:
|
|
||||||
.RS
|
|
||||||
.nf
|
|
||||||
# Last Modified: Sun, 19 Jun 2005 15:24:32 +0000
|
|
||||||
# Compiling Time: 0.17 SBU
|
|
||||||
# Maintainer: Name <email@addr.ess>
|
|
||||||
|
|
||||||
pkgname=dvdauthor
|
|
||||||
pkgver=0.6.11
|
|
||||||
pkgrel=3
|
|
||||||
pkgdesc="Will generate a DVD movie from a valid mpeg2 stream"
|
|
||||||
depends=('imagemagick' 'libdvdread')
|
|
||||||
Finclude sourceforge
|
|
||||||
groups=('xapps')
|
|
||||||
archs=('i686' 'x86_64')
|
|
||||||
sha1sums=('a99ea7ef6e50646b77ad47a015127925053d34ea')
|
|
||||||
|
|
||||||
# optimization OK
|
|
||||||
.fi
|
|
||||||
.RE
|
|
||||||
|
|
||||||
As you can see, the setup is fairly simple. The first line tracks the time of
|
|
||||||
the last update, this is automatically updated after a successful build.
|
|
||||||
|
|
||||||
The next line defines its build time. Of course, it depends on your hardware,
|
|
||||||
so we use SBUs instead of minutes as a unit.
|
|
||||||
|
|
||||||
SBU is the Static Binutils Unit, which means the time "repoman merge binutils"
|
|
||||||
takes on your machine. By default makepkg will print out how many seconds the
|
|
||||||
build took. After you built binutils, you should update your /etc/makepkg.conf:
|
|
||||||
|
|
||||||
SBU="257"
|
|
||||||
|
|
||||||
The line above means compiling binutils on your machine took 257 seconds.
|
|
||||||
Starting from this point, makepkg will print out SBUs instead of seconds after
|
|
||||||
successful builds, and this SBU value will be equal on anyone's machine.
|
|
||||||
|
|
||||||
If you wish to maintain the package, write your name or nick and e-mail
|
|
||||||
address to the third line. If you don't plan to maintain the package just wrote
|
|
||||||
the PKGBUILD, then write Contributor instead of Maintainer, and then someone
|
|
||||||
can take it and will add his/her line later. Other lines like "Modified by" are
|
|
||||||
not allowed. Use the darcs patch comments to mention others if you wish.
|
|
||||||
|
|
||||||
pkgname defines the package name. It should not contain any uppercase letters.
|
|
||||||
The package version defines the upstream version, while the package release
|
|
||||||
tracks the Archlinux-specific changes. pkgrel should be an integer, pkgrels
|
|
||||||
like 5wanda1 are reserved for security updates. There the rule is the
|
|
||||||
following: If the original package's pkgrel was 4, then increment it once when
|
|
||||||
you add a security patch, but then use 5wanda1, 5wanda2 and so on. This way
|
|
||||||
the user can easily upgrade to pkgrel=5 which is in -current.
|
|
||||||
|
|
||||||
pkgdesc is a short one-line description for the package. Usually taken from
|
|
||||||
the project's homepage or manpage. Try to keep the lenght under 80 chars.
|
|
||||||
|
|
||||||
depends() is a bash array which defines the dependencies of the package.
|
|
||||||
depends() means the other package is required for building and using the
|
|
||||||
current one. If the dependency is runtime-only, then use rodepends(), if
|
|
||||||
buildtime-only then use makedepends().
|
|
||||||
|
|
||||||
The next line is a special Finclude commands which allows you to inherit
|
|
||||||
any directive from a PKGBUILD scheme. They can be found in the FST,
|
|
||||||
under /source/include. The "util" scheme always included, since its
|
|
||||||
provided functions are used by almost every PKGBUILD. Look at the
|
|
||||||
/source/include/sourceforge.sh, it provides the url, up2date and source()
|
|
||||||
directives, so we don't have to specify them here. After the Finclude you
|
|
||||||
can overwrite the inherited directives, for example define a custom up2date
|
|
||||||
if the inherited one is not sutable for you.
|
|
||||||
|
|
||||||
The groups() array's first element can't be omitted, and it should be a valid
|
|
||||||
"first group". This means it should be in a foo or foo-extra format, where foo
|
|
||||||
or foo-extra is a dir under /source in the FST.
|
|
||||||
|
|
||||||
The archs() array defines for which architectures the given package is
|
|
||||||
available. If it's not available, it means that gensync will skip it when
|
|
||||||
generating package databases. If you are not able to provide a binary package
|
|
||||||
for a given arch, don't include that in archs()! For example, no matter if
|
|
||||||
the package could be compiled in x86_64, if you haven't compiled it yourself,
|
|
||||||
don't include it. If you're sure it won't be available on a given arch (for
|
|
||||||
example it's written in x86 asm), then use !arch, for example !x86_64.
|
|
||||||
|
|
||||||
The sha1sums() array can be generated with the makepkg -g command. Its purpose
|
|
||||||
is to prevent compiling from wrong sources, especially when the build is
|
|
||||||
automatic. Where it is available you can use signatures(), its goal is that
|
|
||||||
you don't have to update it manually every time.
|
|
||||||
|
|
||||||
The last line will be added automatically to the end of the PKGBUILD if the
|
|
||||||
build() function used your $CFLAGS or $CXXFLAGS. This is handy if you want to
|
|
||||||
cross-compile on a faster machine for a slower architecture. Until the package
|
|
||||||
doesn't use our $CFLAGS we can't cross-compile it, so please try to avoid
|
|
||||||
creating "unoptimized" packages. If the package doesn't contain any
|
|
||||||
architecture-dependent file, then you can add this line manually as makepkg
|
|
||||||
will not detect this.
|
|
||||||
|
|
||||||
Finally we define a build() function that will build the package. If you don't
|
|
||||||
want to do anything special, probably you don't have to specify anything, as
|
|
||||||
the default build() (inherited from util.sh) will fit your needs. Even if you
|
|
||||||
define a custom build(), probably you can re-use parts of the default build().
|
|
||||||
For the list of special functions provided by util.sh and others refer to
|
|
||||||
the /source/include dir. Again, util.sh is included automatically, but you
|
|
||||||
have to Finclude the others before using them!
|
|
||||||
|
|
||||||
Once the package is successfully installed into the package root, \fImakepkg\fP
|
|
||||||
will prepare some documentation. It will
|
|
||||||
then strip debugging info from libraries and binaries and generate a meta-info
|
|
||||||
file. Finally, it will compress everything into a .fpm file and leave it
|
|
||||||
in the directory you ran \fBmakepkg\fP from.
|
|
||||||
|
|
||||||
At this point you should have a package file in the current directory, named
|
|
||||||
something like name-version-release-arch.fpm. Done!
|
|
||||||
|
|
||||||
.SH Install/Upgrade/Remove Scripting
|
|
||||||
Pacman has the ability to store and execute a package-specific script when it
|
|
||||||
installs, removes, or upgrades a package. This allows a package to "configure
|
|
||||||
itself" after installation and do the opposite right before it is removed.
|
|
||||||
|
|
||||||
The exact time the script is run varies with each operation:
|
|
||||||
.TP
|
|
||||||
.B pre_install
|
|
||||||
script is run right before files are extracted.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B post_install
|
|
||||||
script is run right after files are extracted.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B pre_upgrade
|
|
||||||
script is run right before files are extracted.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B post_upgrade
|
|
||||||
script is run after files are extracted.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B pre_remove
|
|
||||||
script is run right before files are removed.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B post_remove
|
|
||||||
script is run right after files are removed.
|
|
||||||
|
|
||||||
.RE
|
|
||||||
To use this feature, just create a file (eg, pkgname.install) and put it in
|
|
||||||
the same directory as the PKGBUILD script. Then use the \fIinstall\fP directive:
|
|
||||||
.RS
|
|
||||||
.nf
|
|
||||||
install=pkgname.install
|
|
||||||
.fi
|
|
||||||
.RE
|
|
||||||
|
|
||||||
The install script does not need to be specified in the \fIsource\fP array.
|
|
||||||
If you omit the install directive then makepkg will check for the
|
|
||||||
$pkgname.install install and will use it if it's present.
|
|
||||||
|
|
||||||
You can find a scriptlet skeleton in the /docs/tech/skel/ directory, use it
|
|
||||||
when creating new packages.
|
|
||||||
|
|
||||||
The scriptlet messages are parsed, a simple example tells you everything:
|
|
||||||
.nf
|
|
||||||
post_upgrade()
|
|
||||||
{
|
|
||||||
echo "START this will be good"
|
|
||||||
echo "DONE 0"
|
|
||||||
echo "START this will fail"
|
|
||||||
echo "DONE 1"
|
|
||||||
echo "old message"
|
|
||||||
}
|
|
||||||
.fi
|
|
||||||
|
|
||||||
.SH PKGBUILD Directives
|
|
||||||
.TP
|
|
||||||
.B pkgname
|
|
||||||
The name of the package. This has be a unix-friendly name as it will be
|
|
||||||
used in the package filename.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B pkgver
|
|
||||||
This is the version of the software as released from the author (eg, 2.7.1).
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B pkgrel
|
|
||||||
This is the release number specific to Archlinux Linux packages.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B pkgdesc
|
|
||||||
This should be a brief description of the package and its functionality.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B pkgdesc_localized
|
|
||||||
Array of the localized package descriptions.
|
|
||||||
|
|
||||||
The format is the following:
|
|
||||||
pkgdesc_localized=('xx_YY foo' 'xx_YY bar')
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B url
|
|
||||||
This field contains an optional URL that is associated with the piece of software
|
|
||||||
being packaged. This is typically the project's website.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B license
|
|
||||||
Sets the license type (eg, "GPL", "BSD", "NON-FREE"). (\fBNote\fP: This
|
|
||||||
option is still in development and may change in the future)
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B install
|
|
||||||
Specifies a special install script that is to be included in the package.
|
|
||||||
This file should reside in the same directory as the PKGBUILD, and will be
|
|
||||||
copied into the package by makepkg. It does not need to be included in the
|
|
||||||
\fIsource\fP array. (eg, install=modutils.install)
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B up2date
|
|
||||||
This directive should contain a command that prints the current upstream stable
|
|
||||||
version of the project. This way we can check for newer version without visiting
|
|
||||||
manually the project's website (see above).
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B source \fI(array)\fP
|
|
||||||
The \fIsource\fP line is an array of source files required to build the
|
|
||||||
package. Source files must reside in the same directory as the PKGBUILD
|
|
||||||
file, unless they have a fully-qualified URL. Then if the source file
|
|
||||||
does not already exist in /var/cache/pacman/src, the file is downloaded
|
|
||||||
by wget.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B md5sums \fI(array)\fP
|
|
||||||
If this field is present, it should contain an MD5 hash for every source file
|
|
||||||
specified in the \fIsource\fP array (in the same order). makepkg will use
|
|
||||||
this to verify source file integrity during subsequent builds. To easily
|
|
||||||
generate md5sums, first build using the PKGBUILD then run
|
|
||||||
\fBmakepkg -G >>PKGBUILD\fP. Then you can edit the PKGBUILD and move the
|
|
||||||
\fImd5sums\fP line from the bottom to an appropriate location.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B sha1sums \fI(array)\fP
|
|
||||||
If this field is present, it should contain an SHA1 hash for every source file
|
|
||||||
specified in the \fIsource\fP array (in the same order). makepkg will use
|
|
||||||
this to verify source file integrity during subsequent builds. To easily
|
|
||||||
generate sha1sums, first build using the PKGBUILD then run
|
|
||||||
\fBmakepkg -g >>PKGBUILD\fP. Then you can edit the PKGBUILD and move the
|
|
||||||
\fIsha1sums\fP line from the bottom to an appropriate location.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B signatures \fI(array)\fP
|
|
||||||
If this field is present, it should contain an array of gpg signatures required
|
|
||||||
to validate the source files. Where there is no signature available just leave
|
|
||||||
it empty, like:
|
|
||||||
|
|
||||||
signatures=(${source[0]}.asc '')
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B groups \fI(array)\fP
|
|
||||||
This is an array of symbolic names that represent groups of packages, allowing
|
|
||||||
you to install multiple packages by requesting a single target. For example,
|
|
||||||
one could install all KDE packages by installing the 'kde' group.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B archs \fI(array)\fP
|
|
||||||
This array defines on which architectures the given package is avalibable.
|
|
||||||
If it's not available, that will mean that gensync will skip it when generating
|
|
||||||
package databases.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B backup \fI(array)\fP
|
|
||||||
A space-delimited array of filenames (without a preceding slash). The
|
|
||||||
\fIbackup\fP line will be propagated to the package meta-info file for
|
|
||||||
pacman. This will designate all files listed there to be backed up if this
|
|
||||||
package is ever removed from a system. See \fBHANDLING CONFIG FILES\fP in
|
|
||||||
the \fIpacman\fP manpage for more information.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B depends \fI(array)\fP
|
|
||||||
An array of packages that this package depends on to build and run. Packages
|
|
||||||
in this list should be surrounded with single quotes and contain at least the
|
|
||||||
package name. They can also include a version requirement of the form
|
|
||||||
\fBname<>version\fP, where <> is one of these three comparisons: \fB>=\fP
|
|
||||||
(greater than equal to), \fB<=\fP (less than or equal to), or \fB=\fP (equal to).
|
|
||||||
See the PKGBUILD example above for an example of the \fIdepends\fP directive.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B makedepends \fI(array)\fP
|
|
||||||
An array of packages that this package depends on to build (ie, not required
|
|
||||||
to run). Packages in this list should follow the same format as \fIdepends\fP.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B rodepends \fI(array)\fP
|
|
||||||
An array of packages that this package depends on to run (ie, not required to
|
|
||||||
build). Generally \fIrodepends\fP should be avoided in favour of \fIdepends\fP
|
|
||||||
except where this will create circular dependency chains. (For example building
|
|
||||||
logrotate doesn't requires to have dcron installed.) Packages in this list
|
|
||||||
should follow the same format as \fIdepends\fP.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B conflicts \fI(array)\fP
|
|
||||||
An array of packages that will conflict with this package (ie, they cannot both
|
|
||||||
be installed at the same time). This directive follows the same format as
|
|
||||||
\fIdepends\fP except you cannot specify versions here, only package names.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B provides \fI(array)\fP
|
|
||||||
An array of "virtual provisions" that this package provides. This allows a package
|
|
||||||
to provide dependency names other than it's own package name. For example, the
|
|
||||||
kernel-scsi and kernel-ide packages can each provide 'kernel' which allows packages
|
|
||||||
to simply depend on 'kernel' rather than "kernel-scsi OR kernel-ide OR ..."
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B replaces \fI(array)\fP
|
|
||||||
This is an array of packages that this package should replace, and can be used to handle
|
|
||||||
renamed/combined packages. For example, if the kernel package gets renamed
|
|
||||||
to kernel-ide, then subsequent 'pacman -Syu' calls will not pick up the upgrade, due
|
|
||||||
to the differing package names. \fIreplaces\fP handles this.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
.B options \fI(array)\fP
|
|
||||||
This is an array of various boolean options. The possible values are:
|
|
||||||
.nf
|
|
||||||
nodocs Don't add any documentation automatically (ie. when there'll be
|
|
||||||
a separate documentation subpackage).
|
|
||||||
nostrip Don't strip binaries/libraries.
|
|
||||||
force This is used to force the package to be upgraded by --sysupgrade,
|
|
||||||
even if its an older version.
|
|
||||||
nobuild If this directive set, gensync will ignore this package, so users
|
|
||||||
must build these packages on their machines, they will not be able
|
|
||||||
to install them with pacman -S. Useful for closed-source, but
|
|
||||||
freeware programs.
|
|
||||||
nofakeroot Don't drop privileges after chrooting. Required by some broken
|
|
||||||
packages.
|
|
||||||
scriptlet Don't skip executing scriptlets even if we're in chroot.
|
|
||||||
.fi
|
|
||||||
|
|
||||||
.SH What is the process of chrooted build ?
|
|
||||||
|
|
||||||
First, what is chroot? We currently use fakeroot to prevent build() from
|
|
||||||
modifying the host system, and we use a prefix or DESTDIR directive to install
|
|
||||||
everything to a directory and not under to the host system. This is good, but
|
|
||||||
not enough.
|
|
||||||
|
|
||||||
This system lacks of the ability to control the list of installed packages
|
|
||||||
during the build on the system of a packager, the given compiled package maybe
|
|
||||||
linked itself to an extra installed library. This way we can't really control
|
|
||||||
the list of real dependencies. For example if libquicktime is installed from
|
|
||||||
source on my system, then mplayer or any other program can link itself to that,
|
|
||||||
and so that depends() will be incorrect. Or if I have the closed source binary
|
|
||||||
NVidia drivers installed, some programs link tho NVidia's libraries.
|
|
||||||
|
|
||||||
Of course there is a sollution to avoid this, to use a real chroot instead of a
|
|
||||||
simple fakeroot. What is this means? The followings:
|
|
||||||
|
|
||||||
When starting the build, a core chroot system is installed under /var/chroot.
|
|
||||||
(Of course you can change this value under /etc/makepkg.conf.) The core system
|
|
||||||
contains ~60 packages which are must installed to build any package in
|
|
||||||
a chrooted environment. These packages (for example gcc, kernel-headers, make)
|
|
||||||
should not be mentioned in makedepends(). 'pacman -Sg core chroot-core
|
|
||||||
devel-core' should show you the actial list. (We try to change this list rarely
|
|
||||||
of course.)
|
|
||||||
|
|
||||||
When you start building with makepkg -R, pacman will install these packages to
|
|
||||||
/var/chroot if necessary. This will produce a fully "clean" Archlinux system,
|
|
||||||
that consits of base packages only. This /var/chroot is fully separated from
|
|
||||||
the host system so that this will solve the problems mentioned above.
|
|
||||||
(Linking to a library installed from source, etc.)
|
|
||||||
|
|
||||||
Here comes the fun part. The packages listed in depends() and makedepends() are
|
|
||||||
installed to this clean (/var/chroot) system. From this point, this chroot is
|
|
||||||
capable to build the specified package in it without any unnecessary package
|
|
||||||
installed, fully separated from the host system.
|
|
||||||
|
|
||||||
After this the chroot should be cleaned up which means the removal of the
|
|
||||||
installed depends() and makedepends(). This ensures us not to build from
|
|
||||||
scratch the core chroot.
|
|
||||||
|
|
||||||
This way we can prevent lots of dependency problems and it is even possible to
|
|
||||||
build packages for a different Archlinux version. This is quite efficent when
|
|
||||||
building security updates or fixing critical bugs in the -stable tree.
|
|
||||||
|
|
||||||
If the build is failed, the working directory will not be deleted, you can find
|
|
||||||
it under /var/chroot/var/tmp/fst. Later if you want to clean your chroot
|
|
||||||
(delete the working directory and remove unnecessary packages) you can use 'makepkg -CR'.
|
|
||||||
|
|
||||||
To activate building in a chroot, you should run makepkg as root at least with
|
|
||||||
the -R option.
|
|
||||||
|
|
||||||
.SH Package splitting
|
|
||||||
|
|
||||||
Package splitting means moving out a list of specifed files to subpackages (like
|
|
||||||
libmysql out of mysql) and then defining the properties of subpackages.
|
|
||||||
|
|
||||||
NOTE: if you create several subpackages, maintaining those packages will
|
|
||||||
require more and more time. Thus, unnecessary splits aren't welcome.
|
|
||||||
Especially, if you split out a library, then don't move the headers to the
|
|
||||||
package just to speed up building with a few seconds!
|
|
||||||
|
|
||||||
The \fBsubpkgs()\fP array is to define the pkgnames of the subpackages. From
|
|
||||||
now all the directives has their subfoo equivalent:
|
|
||||||
.nf
|
|
||||||
pkgname -> subpkgs()
|
|
||||||
pkgdesc -> subdescs()
|
|
||||||
pkgdesc_localized -> subdescs_localized()
|
|
||||||
license() -> sublicense()
|
|
||||||
replaces() -> subreplaces()
|
|
||||||
groups() -> subgroups()
|
|
||||||
depends() -> subdepends()
|
|
||||||
rodepends() -> subrodepends()
|
|
||||||
removes() -> subremoves()
|
|
||||||
conflicts() -> subconflicts()
|
|
||||||
provides() -> subprovides()
|
|
||||||
backup() -> subbackup()
|
|
||||||
install -> subinstall()
|
|
||||||
options -> suboptions()
|
|
||||||
archs -> subarchs()
|
|
||||||
.fi
|
|
||||||
|
|
||||||
Also note that bash does not support two-dimensional arrays, so when defining the
|
|
||||||
array of arrays, then quotes are the major separators and spaces are the minor ones.
|
|
||||||
|
|
||||||
Simple example:
|
|
||||||
.nf
|
|
||||||
Add the followings to your bottom of your PKGBUILD
|
|
||||||
subpkgs=('foo' 'bar')
|
|
||||||
subdescs=('desc of foo' 'desc of bar')
|
|
||||||
subdepends=('foodep1 foodep2' 'bardep1 bardep2')
|
|
||||||
subgroups=('apps' 'apps')
|
|
||||||
subarchs=('i686 x86_64' 'i686 x86_64')
|
|
||||||
.fi
|
|
||||||
|
|
||||||
You may define conflicts, replaces and other directives for your subpackages, but
|
|
||||||
the requirement is only to define these 5 ones.
|
|
||||||
|
|
||||||
The second part is to move some files to the - just defined - subpackages. You
|
|
||||||
should use the Fsplit command for this at the end of your build() function. You
|
|
||||||
can read more about Fsplit in the fwmakepkg documentation, but here is a short
|
|
||||||
example:
|
|
||||||
.nf
|
|
||||||
|
|
||||||
Fsplit subpkgname usr/share/
|
|
||||||
|
|
||||||
.fi
|
|
||||||
This will move the /usr/share dir of the package to the "subpkgname" subpackage.
|
|
||||||
|
|
||||||
NOTE: never use a trailing slash when defining file patterns, especially if you
|
|
||||||
use wildcards in it!
|
|
||||||
|
|
||||||
.SH "SEE ALSO"
|
|
||||||
.BR makepkg (8),
|
|
||||||
.BR pacman (8)
|
|
||||||
.SH AUTHOR
|
|
||||||
.nf
|
|
||||||
Judd Vinet <jvinet@zeroflux.org>
|
|
||||||
and the Frugalware developers <frugalware-devel@frugalware.org>
|
|
||||||
.fi
|
|
Loading…
Add table
Reference in a new issue