ノンフリーアプリケーションパッケージガイドライン

提供: ArchWiki
2023年6月28日 (水) 14:43時点におけるKgx (トーク | 投稿記録)による版 (→‎高度なトピック: pkgver の自動バンピングを翻訳して追加)
ナビゲーションに移動 検索に移動
パッケージ作成ガイドライン

32ビット – CLR – クロス – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE – カーネル – Lisp – MinGW – Node.js – ノンフリー – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – ウェブ – Wine

アプリケーションによっては (特に Windows のアプリケーション) ソースや tarball が手に入らない場合があります。そのようなアプリケーションの多くはライセンスの制約があったり、あるいは無料で合法的にインストーラーを取得する方法が存在せず、自由に再配布することができません。当然それらのソフトウェアを公式リポジトリに入れることはできませんが、AUR であれば私的にソフトウェアのパッケージをビルドして pacman で管理するということが不可能ではありません。

ノート: この記事に書かれている情報はパッケージに依存しません。一般的なフリーではないソフトウェアに関する情報は Wine パッケージガイドラインを見てください。

根拠

パッケージになっていないソフトウェアもパッケージ化する理由は複数あります:

  • インストールやアンインストールの平易化
/usr/bin にスクリプトをインストールするだけのシンプルなアプリでも意味があります。通常は以下のコマンドを実行するところを:
$ chmod +x filename
# chown root:root filename
# cp filename /usr/bin/
以下のコマンドだけでパッケージを作成できます:
$ makepkg -i
フリーでないアプリケーションは大抵複雑ですが、パッケージスクリプトを書くことで、ホームページから圧縮ファイルやインストーラをダウンロードして、展開・復号化してから、ランチャースクリプトを手動で書くような作業の負担を少なくすることができます。
  • pacman の機能の利用
ソフトウェアの状態の追跡、インストール済みのソフトウェアの自動アップデート、全てのファイルの所有権管理、管理が行き届いたキャッシュに圧縮パッケージを保存することなどが可能になり GNU/Linux ディストリビューションの強みを活かせます。
  • コードや知識の共有
プロプライエタリの開発者にパッチを送信したり普遍的なフォーラムで質問を投げるよりも AUR のような場所のほうが設定を変更したりバグフィックスを当てたり助けを得ることが楽になります。

一般的なルール

可能なかぎりフリーでないソフトウェアは避ける

このガイドは脇に置いて、パッケージ化したいアプリケーションの代わりとなるアプリケーションが存在しないか検索 (あるいは作成) するのに時間を費やしたほうが有益です:

  1. フリーでないソフトウェアのパッケージングは面倒であり大抵 The Arch Way に反しています
  2. 一企業によって所有されているソフトウェアよりも全員で共有しているソフトウェアを支援したほうが有益です
  3. 活発に開発されているソフトウェアを支援したほうが有益です
  4. ユーザーのだれか一人でも面倒をみることができれば修正が可能なソフトウェアを支持するほうが有益です

可能なかぎりオープンソースのソフトウェアを使う

多くの商用ゲーム (ゲーム一覧) はオープンソースのエンジンを使っており古いゲームの多くは ScummVM などのエミュレータで遊ぶことができます。オープンソースエンジンとオリジナルのゲームアセットを使うことで、バイナリパッケージによる問題を回避したりバグを解決することが可能です。

Keep it simple

オリジナルのバージョンを購入して使用するのと比べてパッケージ化するために複雑な作業やハックが必要な場合、簡単なほうの方法を使ってください。

パッケージの命名

勝手に名前を付ける前に、パッケージ化したいソフトウェアが AUR に既に存在しないか検索してください。パッケージが存在する場合、それらの命名規則に従うようにしてください (例えば aquaria-hibAUR, penumbra-overture-hibAUR, uplink-hibAUR というパッケージが存在するのに gish-hb という名前のパッケージを作成するのは止めてください)。ソースベースのパッケージが絶対に存在しないという確信がないかぎり、必ず -bin をパッケージの後ろに付けてください。

ファイルの置き場所

既存のパッケージを解析して、ファイルが衝突しないように注意してください。パッケージディレクトリの所有権を root:games にするような汚いハックを使う必要がないのであれば、ファイルを /opt には配置しないでください。

欠けているファイル

ほとんどの商用ゲームはゲームファイルを (合法的に) ダウンロードする手段を用意しておらず、通常パッケージからインストールするようになっています。(Humble Indie Bundle のゲームのように) パスワードを入力すればファイルをダウンロードすることが可能な場合でも、build 関数の中でダウンロードを行うことは様々な理由で推奨できません (例えば、ユーザーはインターネットに接続できない環境でローカルにファイルを全てダウンロード・保存している場合などが考えられます)。そのような場合、以下の方法があります:

  • ファイルを取得する方法がひとつしかない場合:
  • ソフトウェアが圧縮ファイル/インストーラーで配布されている場合:
必要なファイルを sources 配列に追加:
sources=(... "originalname::file://originalname")
AUR ウェブインターフェイスのファイルリンクはソース tarball に含まれているファイルの名前とは異なるようになります。
パッケージのページに以下のようなコメントを残してください:
Need archive/installer to work.
そして PKGBUILD の中で詳細に説明してください。
  • ソフトウェアがコンパクトディスクで配布されている場合:
tsukihime-enAUR[リンク切れ: アーカイブ: aur-mirror] パッケージのように、インストーラースクリプトと .install ファイルを追加してください。
  • ファイルを取得する方法が複数存在する場合:
build の中でディスクからファイルをコピーしたり、ネットからファイルをダウンロードしたり圧縮ファイルから展開することは良いアイデアに思えるかもしれませんが非推奨です。ユーザーの利便性を損なう可能性があり、パッケージのインストールをするときにユーザーの操作が必要になるためです。インストーラスクリプトと .install ファイルを使ってください。

パッケージに必要なファイルを取得するための様々な手段の例:

高度なトピック

カスタム DLAGENTS

ソフトウェアによっては自動ダウンロードからソフトウェアが積極的に保護されている場合もあります: 特定の "User-Agent" 文字列のアクセスを拒否したり、ファイルの一時リンクを作成することなどが挙げられます。そういった場合でも、PKGBUILD で DLAGENTS 変数を使うことでファイルを楽にダウンロードすることができます (makepkg.conf(5) を参照)ttf-baekmuk など、公式リポジトリのパッケージでも使われているものがあります。

ユーザーエージェント文字列をカスタマイズする場合、空白や括弧、スラッシュが含まれていると動作しなくなります。Bash の制限のため解決方法はありません。例えば以下の例は機能しません: 

DLAGENTS=("http::/usr/bin/curl -A 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)' -fLC - --retry 3 --retry-delay 3 -o %o %u")

以下のようにすることで機能します: 

DLAGENTS=("http::/usr/bin/curl -A 'Mozilla' -fLC - --retry 3 --retry-delay 3 -o %o %u")

また、以下を使うことでダウンロードページからファイルの一時リンクを抽出することが可能です: 

DLAGENTS=("http::/usr/bin/wget -r -np -nd -H %u")

解凍

プロプライエタリなプログラムの多くは扱いにくいインストーラーを使っており Wine でも動作しないことがしばしばです。以下のツールを使うことで解凍できる場合があります:

  • unzip と unrar は実行ファイルの SFX アーカイブを解凍できます。
  • cabextract は大抵の .cab ファイルを解凍できます (.exe 拡張子のファイルも解凍可能です)
  • unshield は InstallShield インストーラーから CAB ファイルを抽出できます。
  • p7zip は大抵の圧縮形式を解凍できるだけでなく NSIS ベースの .exe インストーラーも解凍できます。
    • 一般的な PE (.exe & .dll) ファイルから一部だけを抽出することも可能です。
  • 実行ファイルが暗号化されている場合 upx によって復号化できることがあります。
  • innoextract は Inno Setup によって作成された .exe インストーラーを解凍できます (GOG.com のゲームなどで使われています)

ファイルのタイプを確認するには file file_of_unknown_type を実行してください。

.desktop ファイル用のアイコンの取得

プロプライエタリなソフトウェアはアイコンファイルを用意してないことが少なくなく、.desktop ファイルを作成するときに使えるアイコンがないことがあります。icoutils パッケージに含まれているプログラムを使うことで実行ファイルから .ico ファイルは簡単に抽出できます。build 関数の中で抽出をすることもできます: 

$ wrestool -x --output=icon.ico -t14 executable.exe

pkgver の自動バンピング

非フリーソフトウェアベンダーは、ダウンロードソース URL にバージョン番号を含めないことがよくあります。 

source=('https://downloads.example.com/NonFreePackageWithPoorFileName.exe')

そのため、リリースアップストリームのパッケージが予告なく変更される可能性があり、これがパッケージ化の問題となります。 VCS パッケージ と同様に、auto-bump pkgver を使用してこれを処理することもできます。

インストーラーパッケージから

たとえば、一部の .exe インストーラーでは、PE に [製品バージョン] フィールドが設定されています。pevAUR パッケージの peres コマンドは、その値を抽出して使用して、pkgver を自動バンプするのに役立ちます。 

pkgver=VERSION
makedepends=('pev')

pkgver() {
  peres -v -f csv "${srcdir}/NonFreePackageWithPoorFileName.exe" \
    | awk -F , '/^Product Version,/ { print $2 }'
}

メインの実行可能ファイルから

場合によっては、.exe インストーラーには 製品バージョン の意味のある値が含まれていないが、メインの実行可能ファイルには含まれていることがあります。その場合、prepare ステップを使用して、ネストされたメイン実行可能ファイルを抽出し (詳細については 解凍 を参照)、その後、pkgver を自動バンプすることができます。

例えば: 

pkgver=VERSION
makedepends=('p7zip' 'pev')

prepare() {
  mkdir -p "${srcdir}/${pkgname}-unpacked"
  7z x -o"${srcdir}/${pkgname}-unpacked" "${srcdir}/NonFreePackageWithPoorFileName.exe"
}

pkgver() {
  peres -v -f csv "${srcdir}/${pkgname}-unpacked/NonFreeApp.exe" \
    | awk -F , '/^Product Version,/ { print $2 }'
}
「https://wiki.archlinux.jp/index.php?title=ノンフリーアプリケーションパッケージガイドライン&oldid=32431」から取得