Creating packages for other distributions

From ArchWiki

Arch is the best. But you may still want to package for other distributions.

General

  • Virtualization is an obvious way, but requires maintaining additional system(s).
  • Use distribution-specific packaging tools. Examples: dh-makeAUR, dpkg (Debian), rpm-tools (Fedora). Shortcuts such as dpkg-deb may be suited for less complex tasks.
  • Chroot or systemd-nspawn to create a base system inside (yet separate from) Arch. Examples: debootstrap (Debian), dnf (Fedora). This has the added benefit of building in a minimal, clean environment.
  • Use chroot with packaging tools in an an automated fashion. Examples: pbuilder-ubuntuAUR (Debian).
  • A different way to handle (possibly incompatible) dependencies is static linking. Please note that most distributions frown on this practice.
  • Common practice applies regardless of distribution used. For example, do not build packages as root.

Debian

The Debian Packaging Tutorial explains the groundwork. It describes use of the following tools:

This article or section needs expansion.

Reason: Missing tools: lintian, reprepo, cdbs, svn-buildpackage, javahelper (Discuss in Talk:Creating packages for other distributions)
  • cowdancer — Copy-on-write wrapper for pbuilder
https://packages.debian.org/sid/cowdancer || cowdancerAUR
  • debootstrap — A tool used to create a Debian base system from scratch, without requiring the availability of dpkg or apt.
https://packages.debian.org/sid/debootstrap || debootstrap
  • devscripts — Scripts to make the life of a Debian Package maintainer easier
https://packages.debian.org/sid/devscripts || devscriptsAUR
  • dh-strip-nondeterminism — Tool for stripping bits of non-deterministic information from files, supports dh
https://salsa.debian.org/reproducible-builds/strip-nondeterminism || dh-strip-nondeterminismAUR
  • dh-autoreconf — Debhelper add-on to call autoreconf and clean up after the build
https://packages.debian.org/sid/dh-autoreconf || dh-autoreconfAUR
  • dh-make — Tool that converts source archives into Debian package source
https://packages.debian.org/sid/dh-make || dh-makeAUR
  • dpkg — The Debian Package Manager
https://packages.debian.org/sid/dpkg || dpkg
  • dput — Debian package upload tool
https://packages.debian.org/sid/dput || dputAUR
  • equivs — Circumvent Debian package dependencies
https://launchpad.net/ubuntu/+source/equivs || equivsAUR[broken link: package not found]
  • git-buildpackage — Tools from Debian to integrate the package build system with Git
https://honk.sigxcpu.org/piki/projects/git-buildpackage/ || git-buildpackageAUR
  • pbuilder-ubuntu — Chroot environment for building Debian packages
https://launchpad.net/ubuntu/+source/pbuilder || pbuilder-ubuntuAUR
  • quilt — Manage a series of patches by keeping track of the changes each patch makes
https://savannah.nongnu.org/projects/quilt || quilt

Tips and Tricks about Debian

Override dependency handling

dpkg does not recognize dependencies installed by pacman. This means dpkg-buildpackage will generally fail with errors such as:

dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native debhelper (>= 8.0.0)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting

To override this, use the -d flag:

$ dpkg-buildpackage -d -us -uc

You may also need to override dh_shlibdeps by adding the following lines to debian/rules:

override_dh_shlibdeps:
   dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info
Note: Any run-time dependencies (and matching version numbers) should be added manually to debian/control, where ${shlibs:Depends} now has no meaning.
Warning: Even if you manage to successfully build a package this way, it is strongly recommended to build in a clean environment (such as chroot) to prevent any incompatibilities.

Set up a chroot

See the Pbuilder How-To for an introduction to pbuilder-ubuntu. Using cowdancer in addition is recommended as copy-on-write offers a significant performance benefit.

  • debian-archive-keyring, ubuntu-keyring and gnupg1AUR are required.
  • eatmydata is available as libeatmydata. To prevent LD_PRELOAD errors, it must be installed both inside and outside the chroot. As the paths are different in Arch and Debian, create the following symbolic links:
# ln -s /usr/lib/libeatmydata.so.1.1.1 /usr/lib/libeatmydata/libeatmydata.so
# ln -s /usr/lib/libeatmydata.so.1.1.1 /usr/lib/libeatmydata/libeatmydata.so.1
$ dpkg-buildpackage -d -us -uc -S

See also about Debian

Fedora

This article or section needs expansion.

Fedora:How to create an RPM package

  • rpm-tools — RPM.org fork, used in major RPM distributions
http://www.rpm.org/ || rpm-tools
  • mock — Takes Source RPMs and builds RPMs from them in a chroot
https://github.com/rpm-software-management/mock/wiki || mockAUR

See also about Fedora

openSUSE

The Open Build Service (OBS) is a generic system to build and distribute packages from sources in an automatic, consistent and reproducible way. It supports at least .deb, .rpm and Arch packages.

Creating Arch packages in OBS with OSC

Note: For building, you must upload your PKGBUILD file as well as the source files (by uploading or letting OBS download the files). OBS uses virtual machines without networking support and cannot download any file.

Creating a package

  1. Create an account in [1]
  2. Install the oscAUR package. Upstream documentation is available here.
  3. Create an example home:foo project.
  4. Create an example home:foo:bar subproject (optional, but recommended).
  5. Create a new ham example package with osc meta pkg -e home:foo:bar ham. Save the created XML then exit.
  6. Switch to a clean working directory then checkout the project you have just created: osc co home:foo:bar/ham.
  7. Now cd into it: cd home:foo:bar/ham.

Managing a package

Now it is time to decide how we will manage our project. There are two practical ways to do this:

  1. Maintain a PKGBUILD plus its helper files (such as *.install scripts) in a version control system (such as git, hg) then just make OBS track it;
  2. Maintain a package entirely in OBS itself.

The first version is more flexible and dynamic. To proceed:

  • From your project directory, create a _service file with the following contents:
<services>
  <service name="tar_scm">
    <param name="scm">git</param>
    <param name="url">git://<your_repo_here></param>
    <param name="versionformat">git%cd~%h</param>
    <param name="versionprefix"><your_version_here></param>
    <param name="filename"><name_of_your_package></param>
  </service>
  <service name="recompress">
    <param name="file">*.tar</param>
    <param name="compression">xz</param>
  </service>
  <service name="set_version"/>
</services>

Here is an example for gimp-gitAUR:

<services>
  <service name="tar_scm">
    <param name="scm">git</param>
    <param name="url">git://git.gnome.org/gimp.git</param>
    <param name="versionformat">git%cd~%h</param>
    <param name="versionprefix">2.9.1</param>
    <param name="filename">gimp-git</param>
  </service>
  <service name="recompress">
    <param name="file">*.tar</param>
    <param name="compression">xz</param>
  </service>
  <service name="set_version"/>
</services>
  • Make OBS track it: osc add _service
  • If you have any other files to include into the repo, just proceed as before: add the files in the project directory, then make OBS track them (OBS uses subversion as its underlying SCM, so this process might already be familiar for you)
  • Check-in (=upload) your files into the repo osc ci -m "commit message (e.g. bumped package xxx to version yyy".

Now, after a while, OBS will begin building your package.

Tips and tricks about openSUSE

This article or section is out of date.

Reason: The git migration is done and [community] is gone. (Discuss in ArchWiki talk:Requests#Git migration)
  • To see the build progress of your package, cd into its working directory, then: osc results.
  • There are three repositories, Arch:Core, Arch:Extra and Arch:Community. [community] can be appended as a "repository path" after adding the main Arch repository to the project.

ca-certificates-utils package problem

If OBS build fails because of the ca-certificates-utils package, you can add this line to your project config (from your project page, go to Advanced -> Project Config).

Prefer: ca-certificates-utils ca-certificates

See also about openSUSE

Multi-distribution

Pacur

Some tools such as Pacur allow building packages for multiple Linux distributions with a consistent package specification format. The package format is very similar to PKGBUILD so it is easy to re-use an existing PKGBUILD and add a few distribution-specific variables to be able to build debian and rpm packages effortlessly. By quickly adapting a PKGBUILD one is able to build package for Amazon Linux, Centos, Debian, Oracle Linux, Fedora and Ubuntu.

See also