Creating packages for other distributions

dpkg does not recognize dependencies installed by pacman. This means 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 by adding the following lines to :

override_dh_shlibdeps:
   dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info

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.

• , and are required.
• eatmydata is available as and . 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

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

• Copr

1. Create an account in
2. Install the package. Upstream documentation is available here.
3. Create an example project.
4. Create an example subproject (optional, but recommended).
5. Create a new example package with . Save the created XML then exit.
6. Switch to a clean working directory then checkout the project you have just created: .
7. Now cd into it: .

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 :

<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:
• 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 .

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

• To see the build progress of your package, cd into its working directory, then: .
• 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.

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

• Example repo: arch-cpu-x-git
• openSUSE packaging guidelines
• Portal:Packaging from openSUSE wiki

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.