「他のディストリビューションのパッケージの作成」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎一般: 同期)
(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-debcheckinstallAUR[リンク切れ: アーカイブ: 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 ラッパー

https://packages.debian.org/sid/cowdancer || cowdancerAUR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://savannah.nongnu.org/projects/quilt || quilt
ノート: 存在しないツール: lintian, reprepo, equivs, cdbs, svn-buildpackage, javahelper

Tips and Tricks

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

dpkgpacman によってインストールされた依存関係を認識しません。そのため 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 を合わせて使うことが推奨されています。

# 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
$ dpkg-buildpackage -d -us -uc -S

参照

Fedora

How to create an RPM package

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 パッケージを作成

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

パッケージの作成

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

パッケージの管理

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

  1. PKGBUILD とヘルパーファイル (*.install スクリプトなど) をバージョン管理システム (git や hg など) で管理して OBS にそれを追跡させる。
  2. 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

参照

参照