With the pacman 3.3 release expected in the coming weeks, I thought I would write about some of the new features that have been added to PKGBUILDs.
The most common change people will make in their PKGBUILDs is to add a package() function. This limits the of fakeroot to only during the file installation steps (so it is not used during the build process). Using fakeroot only during the install stages is considered a “good thing”, but this also provides a workaround for some bugs in fakeroot that can cause issues while attempting to compile a package. A partial example:
install -Dm644 $srcdir/license $pkgdir/usr/share/licenses/$pkgname/license
Note the “cd” step is required in the package() function as makepkg currently does not remember what directory was being used between the build() and package() functions. The package() function is entirely optional, so all PKGBUILDs without one will continue to work as they always have.
The other main feature addition to PKGBUILDs is the ability to create split packages. In Arch Linux, this is useful for packages that are split due to providing separate packages for libraries and binaries (e.g. gcc) or where documentation is too large to justify distributing together with the main package (e.g. ruby). The Arch KDE-4.3 release will also use package splitting, as many lesser used components pulled in a large number of dependencies and made an unsplit KDE install very heavy.
Creating split packages is rather simple. All you have to do is assign an array of package names to the pkgname variable. e.g.
This tells makepkg that it is creating two packages called pkg1 and pkg2. The pkgbase variable is optional, but can be used to hold (e.g.) the upstream package name and is used by makepkg in its output. Each split package requires its own package() function with name in the format package_foo(). e.g. for the above pkgname, the PKGBUILD would have functions package_pkg1() and package_pkg2(). In these functions, the use of the $pkgdir variable is mandatory as it is no longer equivalent to the deprecated $startdir/pkg. All options and directives for the split packages default to the global values given within the PKGBUILD. Most variables can be overridden within the package function. e.g
The pkg1 package will depend on perl while pkg2 does not override the depends array so will depend on glibc. As a general rule, almost every package in the split packages depends array should probably be present in the global makedepends array.
There are several other useful features added to makepkg such as improved handling of info files (automatic removal of $pkgdir/usr/share/info/dir and compression of info files) and being able to specify LDFLAGS in makepkg.conf. Check out a detailed list of changes in the NEWS file in pacman git repo.
For those that want to try out makepkg before the pacman 3.3 release, you can grab a copy of my makepkg-git package which installs alongside the current version of pacman.
Edit – clarified PKGBUILD directive overrides for split packages and added an note about makepkg-git
Nice new features, the split packages will be very useful. I’m looking forward for this new release.
Yes, nice features indeed. Willl the split package feature allow multiple compilation of the same source, e.g. so that the same PKGBUILD could be used to build different versions of Vim (e.g. one with X, one without, etc)?
The idea with package splitting is to compile once to make several packages. If you need to compile twice with different configuration options, then you need two packages
I suppose arch can also be overridden? Then we can have architecture-independent
doc packages; if it’ll be useful I’ll write a namcap information rule which will suggest
separating documentation etc into a different package based on the relative size
From the man page:
The following variables can be overridden: pkgdesc, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options and install.
The “arch” variable is handled differently than others in makepkg (due to CARCH being defined in makepkg.conf) so I guess this was never really thought about. Should be a simple fix but given the close proximity to release, it may only appear in pacman 3.3.1.