Creating packages for other distributions - ArchWiki

# Creating packages for other distributions

Related articles

- Creating packages

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, dpkgAUR (Debian), rpm-orgAUR (Fedora). Shortcuts such as dpkg-deb or checkinstallAUR may be suited for less complex tasks.
- Chroot to create a base system inside (yet separate from) Arch. Examples: debootstrapAUR (Debian), febootstrapAUR (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), mock-gitAUR (Fedora).
- A different way to handle (possibly incompatible) depends 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:

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 || debootstrapAUR

devscripts — Scripts to make the life of a Debian Package maintainer easier

  https://packages.debian.org/sid/devscripts || devscriptsAUR

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 || dpkgAUR

dput — Debian package upload tool

  https://packages.debian.org/sid/dput || dputAUR

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

  http://savannah.nongnu.org/projects/quilt || quilt

Note: Missing tools: lintian, reprepo, equivs, cdbs, svn-buildpackage, javahelper

### Tips and Tricks

#### 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-keyringAUR, ubuntu-keyringAUR and gnupg1AUR from the AUR are required.
- eatmydata is available as libeatmydataAUR and lib32-libeatmydataAUR in the AUR. 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

- Sample pbuilderrc
- To create a source package for pbuilder to handle:

    $ dpkg-buildpackage -d -us -uc -S

### See also

- Debian Policy
- New Maintainers' Guide
- Quilt in Debian packaging

## Fedora

This article or section needs expansion.

Reason: (Discuss in Talk:Creating packages for other distributions#)

How to create an RPM package

rpm-org — RPM.org fork, used in major RPM distros

  http://www.rpm.org/ || rpm-orgAUR

mock — Takes Source RPMs and builds RPMs from them in a chroot

  http://fedoraproject.org/wiki/Projects/Mock || mock-gitAUR

### See also

- Projects/Mock
- Copr

## 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

This section is intended to be a quick reference for automating the build of Arch packages with the openSUSE Build Service.

#### 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've 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

- To see the build progress of your package, cd into its working directory, then: `osc results`.
- There are two repositories, Arch_Core and Arch_Extra. You'll probably want Arch_Extra, since it is more complete. [community] isn't currently available there as of this edit, so if your project has any dependencies in [community], you should include them (manually) in your (sub)project too.
- There is an unofficial arch-community repo here. You might clone a package from there with `osc branch home:roman-neuhauser:arch-community/<package-name> home:foo:bar/<package-name>`.

#### See also

- Example repo: arch-deepin
- openSUSE packaging guidelines
- Portal:Packaging from openSUSE wiki

## See also

- BBS - PKGBUILD equivalents for other distros
- BBS - Original discussion

Category:

- Package development