「他のディストリビューションのパッケージの作成」の版間の差分
(→一般: 同期) |
Kusakata.bot (トーク | 投稿記録) (update Pkg/AUR templates) |
||
9行目: | 9行目: | ||
* [[:Category:仮想化|仮想化]]はわかりやすい方法ですが、追加したシステムの管理が必要になります。 |
* [[:Category:仮想化|仮想化]]はわかりやすい方法ですが、追加したシステムの管理が必要になります。 |
||
− | * ディストリビューションごとのパッケージングツールを使う。例: {{Aur|dh-make}}, {{Aur|dpkg}} (Debian), {{Aur|rpm-org}} (Fedora)。あまり複雑ではない作業には [http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/ dpkg-deb] や {{Aur|checkinstall}} などのショートカットが適しているかもしれません。 |
+ | * ディストリビューションごとのパッケージングツールを使う。例: {{Aur|dh-make}}, {{Aur|dpkg}} (Debian), {{Aur|rpm-org}} (Fedora)。あまり複雑ではない作業には [http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/ dpkg-deb] や {{Aur|checkinstall}}{{Broken package link|{{aur-mirror|checkinstall}}}} などのショートカットが適しているかもしれません。 |
* [[chroot]] して Arch の中に (別に) ベースシステムを作成する。例: {{Pkg|debootstrap}} (Debian), {{Aur|dnf}} (Fedora)。最小限の、クリーンな環境を作れるという利点があります。 |
* [[chroot]] して Arch の中に (別に) ベースシステムを作成する。例: {{Pkg|debootstrap}} (Debian), {{Aur|dnf}} (Fedora)。最小限の、クリーンな環境を作れるという利点があります。 |
||
− | * パッケージングツールによる自動的な方法で chroot を使う。例: {{Aur|pbuilder-ubuntu}} (Debian), {{Aur|mock-git}} (Fedora)。 |
+ | * パッケージングツールによる自動的な方法で chroot を使う。例: {{Aur|pbuilder-ubuntu}} (Debian), {{Aur|mock-git}}{{Broken package link|{{aur-mirror|mock-git}}}} (Fedora)。 |
* (互換性を失う可能性がある) 依存関係を処理する別の方法として [http://jurjenbokma.com/ApprenticesNotes/getting_statlinked_binaries_on_debian.xhtml 静的リンク]。ほとんどのディストリビューションはこの方法を認めてないので注意してください。 |
* (互換性を失う可能性がある) 依存関係を処理する別の方法として [http://jurjenbokma.com/ApprenticesNotes/getting_statlinked_binaries_on_debian.xhtml 静的リンク]。ほとんどのディストリビューションはこの方法を認めてないので注意してください。 |
||
* 使用するディストリビューションに関係なく一般的な原則は適用されます。例えば、[https://bbs.archlinux.org/viewtopic.php?id=67561 パッケージを root でビルドしてはいけません]。 |
* 使用するディストリビューションに関係なく一般的な原則は適用されます。例えば、[https://bbs.archlinux.org/viewtopic.php?id=67561 パッケージを root でビルドしてはいけません]。 |
||
59行目: | 59行目: | ||
* [[AUR]] の {{Aur|debian-archive-keyring}}, {{Aur|ubuntu-keyring}}, {{Aur|gnupg1}} が必要です。 |
* [[AUR]] の {{Aur|debian-archive-keyring}}, {{Aur|ubuntu-keyring}}, {{Aur|gnupg1}} が必要です。 |
||
− | * ''eatmydata'' は [[AUR]] の {{Aur|libeatmydata}} や {{Aur|lib32-libeatmydata}} で入手できます。{{ic|LD_PRELOAD}} エラーが起こらないように、chroot の中と外両方でインストールする必要があります。Arch と Debian ではパスが異なっているため、以下のシンボリックリンクを作成してください: |
+ | * ''eatmydata'' は [[AUR]] の {{Aur|libeatmydata}} や {{Aur|lib32-libeatmydata}}{{Broken package link|{{aur-mirror|lib32-libeatmydata}}}} で入手できます。{{ic|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 |
||
# ln -s /usr/lib/libeatmydata.so.1.1.1 /usr/lib/libeatmydata/libeatmydata.so.1 |
# ln -s /usr/lib/libeatmydata.so.1.1.1 /usr/lib/libeatmydata/libeatmydata.so.1 |
||
77行目: | 77行目: | ||
{{App|rpm-org|RPM.org のフォーク、主要な RPM ディストロで使用されています|http://www.rpm.org/|{{Aur|rpm-org}}}} |
{{App|rpm-org|RPM.org のフォーク、主要な RPM ディストロで使用されています|http://www.rpm.org/|{{Aur|rpm-org}}}} |
||
− | {{App|mock|ソース RPM を取得して chroot で RPM をビルド|http://fedoraproject.org/wiki/Projects/Mock|{{Aur|mock-git}}}} |
+ | {{App|mock|ソース RPM を取得して chroot で RPM をビルド|http://fedoraproject.org/wiki/Projects/Mock|{{Aur|mock-git}}{{Broken package link|{{aur-mirror|mock-git}}}}}} |
=== 参照 === |
=== 参照 === |
2017年5月11日 (木) 08:06時点における版
関連記事
Arch は最高です。しかしながら、時には他のディストリビューションのパッケージを作成したいと思うときもあるでしょう。
目次
一般
- 仮想化はわかりやすい方法ですが、追加したシステムの管理が必要になります。
- ディストリビューションごとのパッケージングツールを使う。例: dh-makeAUR, dpkgAUR (Debian), rpm-orgAUR (Fedora)。あまり複雑ではない作業には dpkg-deb や checkinstallAUR[リンク切れ: アーカイブ: aur-mirror] などのショートカットが適しているかもしれません。
- chroot して Arch の中に (別に) ベースシステムを作成する。例: debootstrap (Debian), dnfAUR (Fedora)。最小限の、クリーンな環境を作れるという利点があります。
- パッケージングツールによる自動的な方法で chroot を使う。例: pbuilder-ubuntuAUR (Debian), mock-gitAUR[リンク切れ: アーカイブ: aur-mirror] (Fedora)。
- (互換性を失う可能性がある) 依存関係を処理する別の方法として 静的リンク。ほとんどのディストリビューションはこの方法を認めてないので注意してください。
- 使用するディストリビューションに関係なく一般的な原則は適用されます。例えば、パッケージを root でビルドしてはいけません。
Debian
Debian パッケージングチュートリアルに基本的なことが説明されています。チュートリアルでは以下のツールの利用について記述しています:
cowdancer — pbuilder の copy-on-write ラッパー
debootstrap — dpkg や apt が利用できない環境でも、スクラッチから Debian ベースシステムを作成するためのツール。
devscripts — Debian パッケージメンテナの生活を楽にするスクリプト
dh-autoreconf — autoreconf を実行してビルド後に片付けを行う Debhelper アドオン
dh-make — ソースアーカイブを Debian パッケージソースに変換するツール
dpkg — Debian パッケージマネージャ
dput — Debian パッケージのアップロードツール
git-buildpackage — Git によるパッケージビルドシステムを統合する Debian のツール
pbuilder-ubuntu — Debian パッケージを作成するための Chroot 環境
quilt — パッチによる変更を記録して一連のパッチを管理する
Tips and Tricks
依存関係の処理を無視する
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
chroot をセットアップ
pbuilder-ubuntu のイントロダクションとして Pbuilder How-To を見て下さい。copy-on-write による著しいパフォーマンスの向上がある cowdancer を合わせて使うことが推奨されています。
- AUR の debian-archive-keyringAUR, ubuntu-keyringAUR, gnupg1AUR が必要です。
- eatmydata は AUR の libeatmydataAUR や lib32-libeatmydataAUR[リンク切れ: アーカイブ: aur-mirror] で入手できます。
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
rpm-org — RPM.org のフォーク、主要な RPM ディストロで使用されています
- http://www.rpm.org/ || rpm-orgAUR
mock — ソース RPM を取得して chroot で RPM をビルド
- http://fedoraproject.org/wiki/Projects/Mock || mock-gitAUR[リンク切れ: アーカイブ: aur-mirror]
参照
openSUSE
Open Build Service は自動的な、一貫した、再現性のある方法でソースからパッケージを作成・配布するための総合システムです。.deb, .rpm そして Arch パッケージをサポートしています。
OBS と OSC で Arch パッケージを作成
パッケージの作成
- [1] でアカウントを作成。
- oscAUR パッケージをインストール。上流のドキュメントは こちら。
- サンプルプロジェクト
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-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>
- OBS に追跡させます:
osc add _service
- リポジトリに含めたい他のファイルが存在する場合、同じように追加してください: プロジェクトディレクトリにファイルを追加して、OBS にファイルを追跡させてください (OBS は基幹の SCM として subversion を使っているため、手順は簡単です)。
- ファイルをリポジトリにチェックイン (アップロード):
osc ci -m "commit message (e.g. bumped package xxx to version yyy"
。
しばらくすると、OBS はパッケージのビルドを開始します。
Tips and tricks
- パッケージのビルドの進捗を確認するには、作業ディレクトリに cd してから次を実行:
osc results
。 - 2つのリポジトリが存在します: Arch_Core と Arch_Extra。この文章を書いている時点では [community] はまだ存在しません。そのため、あなたのプロジェクトが [community] のパッケージに依存する場合、サブプロジェクトとしてプロジェクトに (手動で) 含める必要があります。
- 非公式の arch-community リポジトリが こちら にあります。
osc branch home:roman-neuhauser:arch-community/<package-name> home:foo:bar/<package-name>
でそこからパッケージを複製することが可能です。
ca-certificates-utils パッケージの問題
OBS のビルドが ca-certificates-utils パッケージのせいで失敗する場合、プロジェクトの設定に以下の行を追加してください (プロジェクトのページから、Advanced -> Project Config を開く):
Prefer: ca-certificates-utils ca-certificates