Creating packages for other distributions (Magyar)

Fordítás állapota:
Ez az oldal az angol
Creating packages for other distributions
című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2025.11.02. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb
módosítások
, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.
További oldalak az adott témakörben
Creating packages (Magyar)
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:
abuild
(Alpine),
dh-make
AUR
,
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-ubuntu
AUR
(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
.
Alpine
See
abuild
.
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 (Magyar)
)
cowdancer
— Copy-on-write wrapper for pbuilder
https://packages.debian.org/sid/cowdancer
||
cowdancer
AUR
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
||
devscripts
AUR
dh-autoreconf
— Debhelper add-on to call autoreconf and clean up after the build
https://packages.debian.org/sid/dh-autoreconf
||
dh-autoreconf
AUR
dh-make
— Tool that converts source archives into Debian package source
https://packages.debian.org/sid/dh-make
||
dh-make
AUR
dpkg
— The Debian Package Manager
https://packages.debian.org/sid/dpkg
||
dpkg
dput
— Debian package upload tool
https://packages.debian.org/sid/dput
||
dput
AUR
git-buildpackage
— Tools from Debian to integrate the package build system with Git
https://honk.sigxcpu.org/piki/projects/git-buildpackage/
||
not packaged?
search in AUR
makedeb
— Creates
.deb
packages through PKGBUILD files very similarly to makepkg
https://www.makedeb.org/
||
not packaged?
search in AUR
pbuilder-ubuntu
— Chroot environment for building Debian packages
https://launchpad.net/ubuntu/+source/pbuilder
||
pbuilder-ubuntu
AUR
quilt
— Manage a series of patches by keeping track of the changes each patch makes
https://savannah.nongnu.org/projects/quilt
||
quilt
strip-nondeterminism
— Tool for stripping bits of non-deterministic information from files
https://salsa.debian.org/reproducible-builds/strip-nondeterminism
||
strip-nondeterminism
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
gnupg1
AUR
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
Sample pbuilderrc
To create a source package for pbuilder to handle:
$ dpkg-buildpackage -d -us -uc -S
See also about Debian
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 (Magyar)
)
Fedora Packaging Tutorial
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
||
mock
AUR
See also about Fedora
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
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
Create an account in
[1]
Install
the
osc
AUR
package. Upstream documentation is available
here
.
Create an example
home:foo
project.
Create an example
home:foo:bar
subproject (optional, but recommended).
Create a new
ham
example package with
osc meta pkg -e home:foo:bar ham
. Save the created XML then exit.
Switch to a clean working directory then checkout the project you have just created:
osc co home:foo:bar/ham
.
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:
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;
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-git
AUR
:
<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
Example repo:
arch-cpu-x-git
openSUSE packaging guidelines
Portal:Packaging from openSUSE wiki
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.
További olvasnivaló a témában
BBS - PKGBUILD equivalents for other distros
BBS - Original discussion