他のディストリビューションのパッケージの作成

パッケージの作成

Arch は最高です。しかしながら、時には他のディストリビューションのパッケージを作成したいと思うときもあるでしょう。

一般

仮想化はわかりやすい方法ですが、追加したシステムの管理が必要になります。
ディストリビューションごとのパッケージングツールを使う。例: dh-make^AUR, dpkg (Debian), rpm-org^AUR (Fedora)。あまり複雑ではない作業には dpkg-deb などのショートカットが適しているかもしれません。
chroot して Arch の中に (別に) ベースシステムを作成する。例: debootstrap (Debian), dnf^AUR (Fedora)。最小限の、クリーンな環境を作れるという利点があります。
パッケージングツールによる自動的な方法で chroot を使う。例: pbuilder-ubuntu^AUR (Debian), mock^AUR (Fedora)。
(互換性を失う可能性がある) 依存関係を処理する別の方法として静的リンク。ほとんどのディストリビューションはこの方法を認めてないので注意してください。
使用するディストリビューションに関係なく一般的な原則は適用されます。例えば、パッケージを root でビルドしてはいけません。

Debian

Debian パッケージングチュートリアルに基本的なことが説明されています。チュートリアルでは以下のツールの利用について記述しています:

cowdancer — pbuilder の copy-on-write ラッパー

https://packages.debian.org/sid/cowdancer || cowdancer^AUR

debootstrap — dpkg や apt が利用できない環境でも、スクラッチから Debian ベースシステムを作成するためのツール。

https://packages.debian.org/sid/debootstrap || debootstrap

devscripts — Debian パッケージメンテナの生活を楽にするスクリプト

https://packages.debian.org/sid/devscripts || devscripts^AUR

dh-autoreconf — autoreconf を実行してビルド後に片付けを行う Debhelper アドオン

https://packages.debian.org/sid/dh-autoreconf || dh-autoreconf^AUR

dh-make — ソースアーカイブを Debian パッケージソースに変換するツール

https://packages.debian.org/sid/dh-make || dh-make^AUR

dpkg — Debian パッケージマネージャ

https://packages.debian.org/sid/dpkg || dpkg

dput — Debian パッケージのアップロードツール

https://packages.debian.org/sid/dput || dput^AUR

equivs — Debian パッケージの依存関係を回避するツール

https://launchpad.net/ubuntu/+source/equivs || equivs^AUR*

git-buildpackage — Git によるパッケージビルドシステムを統合する Debian のツール

https://honk.sigxcpu.org/piki/projects/git-buildpackage/ || git-buildpackage^AUR

pbuilder-ubuntu — Debian パッケージを作成するための Chroot 環境

https://launchpad.net/ubuntu/+source/pbuilder || pbuilder-ubuntu^AUR

quilt — パッチによる変更を記録して一連のパッチを管理する

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

ノート: 存在しないツール: lintian, reprepo, cdbs, svn-buildpackage, javahelper

ヒントとテクニック‎

依存関係の処理を無視する

dpkg は pacman によってインストールされた依存関係を認識しません。そのため dpkg-buildpackage は以下のようなエラーで失敗することになります:

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

これを無視するには、-d フラグを使って下さい:

$ dpkg-buildpackage -d -us -uc

また、以下の行を debian/rules に追加して dh_shlibdeps を上書きする必要もあります:

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

ノート: 実行時の依存関係 (とバージョン番号の一致) を debian/control に手動で追加してください。${shlibs:Depends} はもはや意味を持ちません。

警告: たとえこの方法でパッケージをビルドできたとしても、動かなくなってしまうことがないように (chroot などの) クリーンな環境でビルドを行うことを強く推奨します。

chroot をセットアップ

pbuilder-ubuntu のイントロダクションとして Pbuilder How-To を見て下さい。copy-on-write による著しいパフォーマンスの向上がある cowdancer を合わせて使うことが推奨されています。

AUR の debian-archive-keyring, ubuntu-keyring, gnupg1^AUR が必要です。
eatmydata は libeatmydata や lib32-eatmydata^AUR で入手できます。LD_PRELOAD エラーが起こらないように、chroot の中と外両方でインストールする必要があります。Arch と Debian ではパスが異なっているため、以下のシンボリックリンクを作成してください:

# 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

サンプル pbuilderrc
pbuilder で処理するソースパッケージを作成するには:

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

参照

Fedora

How to create an RPM package

rpm-tools — RPM.org のフォーク、主要な RPM ディストロで使用されています

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

mock — ソース RPM を取得して chroot で RPM をビルド

https://github.com/rpm-software-management/mock/wiki || mock^AUR

参照

Copr

openSUSE

Open Build Service は自動的な、一貫した、再現性のある方法でソースからパッケージを作成・配布するための総合システムです。.deb, .rpm そして Arch パッケージをサポートしています。

OBS と OSC で Arch パッケージを作成

ノート: ビルドするには、PKGBUILD ファイルだけでなくソースファイルもアップロードする必要があります (OBS にアップロードするか OBS からファイルをダウンロードさせるかのどちらか)。OBS はネットワークに対応していない仮想マシンを使っているため、ファイルをダウンロードすることはできません。

パッケージの作成

[1] でアカウントを作成。
osc^AUR パッケージをインストール。上流のドキュメントはこちら。
サンプルプロジェクト home:foo を作成。
サンプルサブプロジェクト home:foo:bar を作成 (任意、ただし推奨)。
osc meta pkg -e home:foo:bar ham で新しいサンプルパッケージ ham を作成。作成された XML ファイルを保存して終了。
新しい作業ディレクトリに切り替えてから作成したプロジェクトをチェックアウト: osc co home:foo:bar/ham。
次のディレクトリに cd: cd home:foo:bar/ham。

パッケージの管理

プロジェクトを管理する方法を決めて下さい。2つの方法が存在します:

PKGBUILD とヘルパーファイル (*.install スクリプトなど) をバージョン管理システム (git や hg など) で管理して OBS にそれを追跡させる。
OBS だけでパッケージを全て管理する。

前者の方法のほうが柔軟性があり動的です。設定するには:

プロジェクトディレクトリから、以下の内容の _service ファイルを作成してください:

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

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>

OBS に追跡させます: osc add _service
リポジトリに含めたい他のファイルが存在する場合、同じように追加してください: プロジェクトディレクトリにファイルを追加して、OBS にファイルを追跡させてください (OBS は基幹の SCM として subversion を使っているため、手順は簡単です)。
ファイルをリポジトリにチェックイン (アップロード): osc ci -m "commit message (e.g. bumped package xxx to version yyy"。

しばらくすると、OBS はパッケージのビルドを開始します。

ヒントとテクニック

パッケージのビルドの進捗を確認するには、作業ディレクトリに cd してから次を実行: osc results。
Arch:Core と Arch:Extra および Arch:Community リポジトリが存在します。[community] can be appended as a "repository path" after adding the main Arch repository to the project.

ca-certificates-utils パッケージの問題

OBS のビルドが ca-certificates-utils パッケージのせいで失敗する場合、プロジェクトの設定に以下の行を追加してください (プロジェクトのページから、Advanced -> Project Config を開く):

Prefer: ca-certificates-utils ca-certificates

参照