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

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

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

根拠

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

• インストールやアンインストールの平易化

/usr/bin にスクリプトをインストールするだけのシンプルなアプリでも意味があります。通常は以下のコマンドを実行するところを:

$ chmod +x filename
# chown root:root filename
# cp filename /usr/bin/

以下のコマンドだけでパッケージを作成できます:

$ makepkg -i

フリーでないアプリケーションは大抵複雑ですが、パッケージスクリプトを書くことで、ホームページから圧縮ファイルやインストーラをダウンロードして、展開・復号化してから、ランチャースクリプトを手動で書くような作業の負担を少なくすることができます。

• pacman の機能の利用

ソフトウェアの状態の追跡、インストール済みのソフトウェアの自動アップデート、全てのファイルの所有権管理、管理が行き届いたキャッシュに圧縮パッケージを保存することなどが可能になり GNU/Linux ディストリビューションの強みを活かせます。

• コードや知識の共有

プロプライエタリの開発者にパッチを送信したり普遍的なフォーラムで質問を投げるよりも AUR のような場所のほうが設定を変更したりバグフィックスを当てたり助けを得ることが楽になります。

一般的なルール

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

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

• 一企業によって所有されているソフトウェアよりも全員で共有しているソフトウェアを支援したほうが有益です
• 活発に開発されているソフトウェアを支援したほうが有益です
• ユーザーのだれか一人でも面倒をみることができれば修正が可能なソフトウェアを支持するほうが有益です

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

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

Keep it simple

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

パッケージの命名

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

ファイルの置き場所

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

欠けているファイル

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

以下のサブセクションでは、遭遇する可能性のあるいくつかの状況に対する推奨事項を示します。

ファイルは分散アーカイブ/インストーラーでのみ入手できます

ソフトウェアは、そのアーカイブ/インストーラーファイル経由でのみ利用可能であり、不足しているファイルを取得するには、アーカイブ/インストーラーファイルを取得する必要があります。

必要なアーカイブ/インストーラーを source 配列に追加し、AUR Web インターフェイス内のソースのリンクがソース tarball に含まれるファイルの名前と異なるように見えるように、ソースファイル名を変更します。

sources=(... "originalname::local://originalname")

また、以下のような固定コメントを AUR のパッケージ ページに追加し、PKGBUILD で詳細を説明します。

Need archive/installer to work.

スキームを選択

ソース配列で local:// スキームを使用する場合、makepkg はスキームが指定されていないかのように動作するため、ファイルは PKGBUILD と同じディレクトリに手動で配置する必要があります。

file:// スキームを使用する場合は、ファイルプロトコルに DLAGENTS を追加で指定できるため、特別な方法で取得できます。 例 下記 を参照してください。

ただし、これらのスキームのどれを使用する必要があるかという明確なルールはまだありません。

ファイルは、配布された CD または他のタイプの光ディスクメディアでのみの場合

ソフトウェアが、光ディスクメディア (CD、DVD、Bluray など) 経由でのみの場合。不足しているファイルを取得するには、光ディスクドライブにメディアを挿入する必要があります。

インストーラースクリプトと .install ファイルをパッケージのコンテンツに追加します。

ファイルはいくつかの方法で取得できます

build フェーズ中にディスクからファイルをコピーしたり、ネットからダウンロードしたり、アーカイブから取得したりすることは良いアイデアのように見えるかもしれませんが、ユーザーの可能性が制限され、パッケージのインストールが対話型になるため、お勧めできません (これは一般的に推奨されず、ただ迷惑なだけです)繰り返しになりますが、適切なインストーラー スクリプトと .install ファイルを代わりに使用できます。

パッケージに必要なファイルを取得するためのさまざまな戦略の例をいくつか示します。

• worldofgoo^AUR – ユーザー提供のファイルへの依存関係

高度なトピック

カスタム 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 に [製品バージョン] フィールドが設定されています。pev^AUR パッケージの 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 }'
}