Difference between revisions of "Makepkg"

From ArchWiki
Jump to navigation Jump to search
(Tips and Tricks: last pacbuilder commit was in 2010, and it has nasty issues like https://code.google.com/p/pacbuilder/issues/detail?id=3)
m (Signature checking: Added search-keys option to doc)
Line 88: Line 88:
 
}}
 
}}
  
To import the key from the server, use:
+
Now you can inspect the missing key using
 +
 
 +
$ gpg --search-keys ''1234567890''
 +
 
 +
If the key seems to be trustworthy, you can import it from the server using:
  
 
  $ gpg --recv-keys ''1234567890''
 
  $ gpg --recv-keys ''1234567890''
  
Or to automate:
+
To automate the process, add the following line to gpg.conf:
  
 
{{hc|~/.gnupg/gpg.conf|
 
{{hc|~/.gnupg/gpg.conf|

Revision as of 14:33, 15 October 2015

zh-CN:Makepkg

makepkg is a script to automate the building of packages. The requirements for using the script are a build-capable Unix platform and a PKGBUILD.

makepkg is provided by the pacman package.

Configuration

See man makepkg.conf for details on configuration options for makepkg.

The system configuration is available in /etc/makepkg.conf, but user-specific changes can be made in $XDG_CONFIG_HOME/pacman/makepkg.conf or ~/.makepkg.conf. It is recommended to review the configuration prior to building packages.

Packager information

Each package is tagged with metadata identifying amongst others also the packager. By default, user-compiled packages are marked with Unknown Packager. If multiple users will be compiling packages on a system, or you are otherwise distributing your packages to other users, it is convenient to provide real contact. This can be done by setting the PACKAGER variable in makepkg.conf.

To check this on an installed package:

$ pacman -Qi package
[...]
Packager       : John Doe <john@doe.com>
[...]

To automatically produce signed packages, also set the GPGKEY variable in makepkg.conf.

Package output

By default, makepkg creates the package tarballs in the working directory and downloads source data directly to the src/ directory. Custom paths can be configured, for example to keep all built packages in ~/build/packages/ and all sources in ~/build/sources/.

Configure the following makepkg.conf variables if needed:

  • PKGDEST — directory for storing resulting packages
  • SRCDEST — directory for storing source data (symbolic links will be placed to src/ if it points elsewhere)
  • SRCPKGDEST — directory for storing resulting source packages (built with makepkg -S)

Signature checking

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Expand a bit on validpgpkeys(), e.g: "I then check the person who signed is expected from the software mailing list, check if they sign emails, look if the PGP fingerprint is published on their homepage, … That verifies the signature enough to add the validpgpkeys array for me." (Discuss in Talk:Makepkg#)

If a signature file in the form of .sig is part of the PKGBUILD source array, makepkg validates the authenticity of source files. For example, the signature pkgname-pkgver.tar.gz.sig is used to check the integrity of the file pkgname-pkgver.tar.gz with the gpg program.

If desired, signatures by other developers can be manually added to the GPG keyring. See GnuPG article for details. To temporarily disable signature checking, call the makepkg command with the --skippgpcheck option.

Note: The signature checking implemented in makepkg does not use pacman's keyring, relying on the user's keyring and the validpgpkeys() array instead. [1]

To show the current list of GPG keys, use the gpg command:

$ gpg --list-keys

If the pubring.gpg file does not exist, it will be created for you immediately.

The GPG keys are expected to be stored in the user's ~/.gnupg/pubring.gpg file. In case it does not contain the given signature, makepkg will abort the installation:

$ makepkg
[...]
==> Verifying source file signatures with gpg...
pkgname-pkgver.tar.gz ... FAILED (unknown public key 1234567890)
==> ERROR: One or more PGP signatures could not be verified!

Make sure that a keyserver is configured in gpg.conf, for example:

~/.gnupg/gpg.conf
keyserver hkp://keys.gnupg.net

Now you can inspect the missing key using

$ gpg --search-keys 1234567890

If the key seems to be trustworthy, you can import it from the server using:

$ gpg --recv-keys 1234567890

To automate the process, add the following line to gpg.conf:

~/.gnupg/gpg.conf
keyserver-options auto-key-retrieve

Usage

Warning: Only build or install packages from trusted sources.

Before continuing, install the base-devel group. Packages belonging to this group are not required to be listed as build-time dependencies (makedepends) in PKGBUILD files. In addition, the base group is assumed to be installed on all Arch systems.

Note:
  • Make sure sudo is configured properly for commands passed to pacman.
  • Running makepkg itself as root is disallowed as of v4.2.[2] Besides how a PKGBUILD may contain arbitrary commands, building as root is generally considered unsafe.[3] Users who have no access to a regular user account should run makepkg as the nobody user.

To build a package, one must first create a PKGBUILD, or build script, as described in Creating packages. Existing scripts are available from the ABS tree or the AUR. Once in possession of a PKGBUILD, change to the directory where it is saved and issue the following command to build the package described by said PKGBUILD:

$ makepkg

If required dependencies are missing, makepkg will issue a warning before failing. To build the package and install needed dependencies, add the flag -s/--syncdeps:

$ makepkg -s

Adding the -r/--rmdeps flag causes makepkg to remove the make dependencies later, which are no longer needed. If constantly building packages, consider using Pacman tips#Removing orphaned packages once in a while instead.

Note:
  • These dependencies must be available in the configured repositories; see pacman#Repositories for details. Alternatively, one can manually install dependencies prior to building (pacman -S --asdeps dep1 dep2).
  • Only global values are used when installing dependencies, i.e any override done in a split package's packaging function will not be used. [4]

Once all dependencies are satisfied and the package builds successfully, a package file (pkgname-pkgver.pkg.tar.xz) will be created in the working directory. To install, use -i/--install (same as pacman -U pkgname-pkgver.pkg.tar.xz):

$ makepkg -i

To clean up leftover files and folders, such as files extracted to the $srcdir, add the option -c/--clean. This is useful for multiple builds of the same package or updating the package version, while using the same build folder. It prevents obsolete and remnant files from carrying over to the new builds:

$ makepkg -c

For more, see makepkg(8).

Tips and Tricks

Creating optimized packages

A performance improvement of the packaged software can be achieved by enabling compiler optimizations for the host machine. The downside is that packages compiled for a specific processor architecture will not run correctly on other machines. On x86_64 machines, there are rarely significant enough real world performance gains that would warrant investing the time to rebuild official packages.

The options passed to a C/C++ compiler (e.g. gcc or clang) are controlled by the CFLAGS, CXXFLAGS, and CPPFLAGS environment variables. Similarly, the make build system uses MAKEFLAGS. For use in the Arch build system, makepkg exposes these environment variables as configuration options in makepkg.conf. The default values are configured to produce generic packages that can be installed on a wide range of machines.

Note: Keep in mind that not all build systems use the variables configured in makepkg.conf. For example, cmake disregards the preprocessor options environment variable, CPPFLAGS. Consequently, many PKGBUILDs contain workarounds with options specific to the build system used by the packaged software.

However, it is very easy to reduce performance by using "nonstandard" compiler flags. Many compiler optimizations are only useful in certain situations and should not be indiscriminately applied to every package. Unless you can verify/benchmark that something is faster, there is a very good chance it is not! The Gentoo Compilation Optimization Guide and Safe CFLAGS wiki article provide more in-depth information about compiler optimization.

As of version 4.3.0, GCC can automatically detect and enable safe architecture-specific optimizations. To use this feature, first remove any -march and -mtune flags, then add -march=native. For example,

CFLAGS="-march=native -O2 -pipe -fstack-protector-strong"

To see what flags this enables on your machine, run:

$ gcc -march=native -v -Q --help=target
Note: To see what architecture GCC detects on your system (rather than which specific flags -march=native sets) you can use the script gcccpuopt.

Optimizing for CPU type may enhance performance because -march=native enables all available instruction sets and improves scheduling for a particular CPU. This could be noticeable with applications that take advantage of newer instructions sets not enabled with the default options provided by Arch Linux (e.g. audio/video encoding tools, scientific applications, math-heavy programs, etc.).

MAKEFLAGS

The MAKEFLAGS option can be used to specify additional options for make. Users with multi-core/multi-processor systems can specify the number of jobs to run simultaneously. This can be accomplished with the use of nproc to determine the number of available processors, e.g. MAKEFLAGS="-j$(nproc)". Some PKGBUILDs specifically override this with -j1, because of race conditions in certain versions or simply because it is not supported in the first place. Packages that fail to build because of this should be reported on the bug tracker (or in the case of AUR packages, to the package maintainer) after making sure that the error is indeed being caused by your MAKEFLAGS.

See man make for a complete list of available options.

Improving compile times

tmpfs

As compiling requires many I/O operations and handling of small files, moving the working directory to a tmpfs may bring improvements in build times.

The BUILDDIR variable can be temporarily exported to makepkg to set the build directory to an existing tmpfs. For example:

$ BUILDDIR=/tmp/makepkg makepkg
Warning: Avoid compiling larger packages in tmpfs to prevent running out of memory.

Persistent configuration can be done in makepkg.conf by uncommenting the BUILDDIR option, which is found at the end of the BUILD ENVIRONMENT section in the default /etc/makepkg.conf file. Setting its value to e.g. BUILDDIR=/tmp/makepkg will make use of the Arch's default /tmp tmpfs.

Note:
  • The tmpfs folder must be mounted without the noexec option, else it will prevent build scripts or utilities from being executed.
  • Keep in mind that any package compiled in tmpfs will not persist across reboot. Consider setting the PKGDEST option appropriately to move the built package automatically to another (persistent) directory.

ccache

The use of ccache can improve build times by caching the results of compilations.

Generate new checksums

Since pacman 4.1, makepkg -g >> PKGBUILD is no longer required because pacman-contrib was merged into upstream pacman, including the updpkgsums script that will generate new checksums and/or replace them in the PKGBUILD. In the same directory as the PKGBUILD file, run the following command:

$ updpkgsums

Create uncompressed packages

If you do not mind having larger package files, you can speed up both packaging and installation by having makepkg produce uncompressed packages. Set PKGEXT='.pkg.tar' in /etc/makepkg.conf.

Utilizing multiple cores on compression

xz supports symmetric multiprocessing (SMP) via the --threads flag to speed up compression. For example, to let makepkg use as many CPU cores as possible to compress packages, add --threads=0 to the COMPRESSXZ array in /etc/makepkg.conf.

Troubleshooting

Makepkg sometimes fails to sign a package without asking for signature passphrase

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: Vague instructions (Discuss in Talk:Makepkg#)

With gnupg 2.1, gpg-agent no longer has to be started manually and will be started automatically on the first invokation of gpg. Thus if you do not manually start gpg-agent, makepkg will start it.

The problem is that makepkg runs gpg inside a fakeroot, so gpg-agent is also started in that same environment. This leads to bad behavior. The obvious remedy is to manually start the gpg-agent, either on boot or by command, before you run makepkg.

See GnuPG#gpg-agent for ways to do this.

CFLAGS/CXXFLAGS/CPPFLAGS in makepkg.conf do not work for QMAKE based packages

Qmake automatically sets the variable CFLAGS and CXXFLAGS according to what it thinks should be the right configuration. In order to let qmake use the variables defined in the makepkg configuration file, you must edit the PKGBUILD and pass the variables QMAKE_CFLAGS_RELEASE and QMAKE_CXXFLAGS_RELEASE to qmake. For example:

PKGBUILD
...

build() {
  cd "$srcdir/$_pkgname-$pkgver-src"
  qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
    PREFIX=/usr \
    CONFIG+=LINUX_INTEGRATED \
    INSTALL_ROOT_PATH="$pkgdir"\
    QMAKE_CFLAGS_RELEASE="${CFLAGS}"\
    QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"

  make
}

...

Alternatively, for a system wide configuration, you can create your own qmake.conf and set the QMAKESPEC environment variable.

WARNING: Package contains reference to $srcdir

Somehow, the literal strings $srcdir or $pkgdir ended up in one of the installed files in your package.

To identify which files, run the following from the makepkg build directory:

$ grep -R "$(pwd)/src" pkg/

Link to discussion thread.

See also