「ノンフリーアプリケーションパッケージガイドライン」の版間の差分

2018年2月23日 (金) 23:58時点における版

パッケージ作成ガイドライン

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 のような場所のほうが設定を変更したりバグフィックスを当てたり助けを得ることが楽になります。

一般的なルール

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

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

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

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

多くの商用ゲーム (ゲーム一覧) はオープンソースのエンジンを使っており古いゲームの多くは 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 関数の中でダウンロードを行うことは様々な理由で推奨できません (例えば、ユーザーはインターネットに接続できない環境でローカルにファイルを全てダウンロード・保存している場合などが考えられます)。そのような場合、以下の方法があります:

ファイルを取得する方法がひとつしかない場合:

ソフトウェアが圧縮ファイル/インストーラーで配布されている場合:

必要なファイルを sources 配列に追加:

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

AUR ウェブインターフェイスのファイルリンクはソース tarball に含まれているファイルの名前とは異なるようになります。

パッケージのページに以下のようなコメントを残してください:

Need archive/installer to work.

そして PKGBUILD の中で詳細に説明してください。

ソフトウェアがコンパクトディスクで配布されている場合:

tsukihime-en^AUR^{[リンク切れ: アーカイブ: aur-mirror]} パッケージのように、インストーラースクリプトと .install ファイルを追加してください。

ファイルを取得する方法が複数存在する場合:

build の中でディスクからファイルをコピーしたり、ネットからファイルをダウンロードしたり圧縮ファイルから展開することは良いアイデアに思えるかもしれませんが非推奨です。ユーザーの利便性を損なう可能性があり、パッケージのインストールをするときにユーザーの操作が必要になるためです。インストーラスクリプトと .install ファイルを使ってください。

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

worldofgoo^AUR – ユーザーが提供するファイルに依存
umineko-en^AUR^{[リンク切れ: アーカイブ: aur-mirror]} – フリーなパッチとユーザーが提供するコンパクトディスクのファイルを混ぜ合わせる
worldofgoo-demo^AUR^{[リンク切れ: アーカイブ: aur-mirror]} – ビルド時にインストーラを自動取得
ut2004-anthology^AUR^{[リンク切れ: アーカイブ: aur-mirror]} – マウントポイントでディスクを検索

高度なトピック

カスタム 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

@@ 9行目: / 9行目: @@
 パッケージになっていないソフトウェアもパッケージ化する理由は複数あります:
 * インストールやアンインストールの平易化
+:{{Ic|/usr/bin}} にスクリプトをインストールするだけのシンプルなアプリでも意味があります。通常は以下のコマンドを実行するところを:
-:This is applicable even to the simplest of apps, which consist of a single script to be installed into {{Ic|/usr/bin}}. Instead of issuing:
+:{{bc|<nowiki>
-:{{bc|$ chmod +x ''filename''}}
+$ chmod +x filename
-:{{bc|# cp ''filename'' /usr/bin/}}
+# chown root:root filename
-:you can type just
+# cp filename /usr/bin/
-:{{bc|# makepkg -i}}
+</nowiki>}}
-:Most non-free applications are obviously much more complicated, but the burden of downloading an archive/installer from a homepage (often full of advertising), unpacking/decrypting it, hand-writing stereotypical launcher scripts and doing other similar tasks can be effectively lightened by a well-written packaging script.
+:以下のコマンドだけでパッケージを作成できます:
+:{{bc|$ makepkg -i}}
+:フリーでないアプリケーションは大抵複雑ですが、パッケージスクリプトを書くことで、ホームページから圧縮ファイルやインストーラをダウンロードして、展開・復号化してから、ランチャースクリプトを手動で書くような作業の負担を少なくすることができます。
 * pacman の機能の利用
+:ソフトウェアの状態の追跡、インストール済みのソフトウェアの自動アップデート、全てのファイルの所有権管理、管理が行き届いたキャッシュに圧縮パッケージを保存することなどが可能になり GNU/Linux ディストリビューションの強みを活かせます。
-:The ability to track state, perform automatic updates of any installed piece of software, determine ownership of every single file, and store compressed packages in a well-organized cache is what makes GNU/Linux distributions so powerful.
 * コードや知識の共有
+:プロプライエタリの開発者にパッチを送信したり普遍的なフォーラムで質問を投げるよりも AUR のような場所のほうが設定を変更したりバグフィックスを当てたり助けを得ることが楽になります。
-:It is simpler to apply tweaks, fix bugs and seek/provide help in a single public place like AUR versus submitting patches to proprietary developers who may have ceased support or asking vague questions on general purpose forums.
 == 一般的なルール ==
@@ 26行目: / 29行目: @@
 # 一企業によって所有されているソフトウェアよりも全員で共有しているソフトウェアを支援したほうが有益です
 # 活発に開発されているソフトウェアを支援したほうが有益です
+# ユーザーのだれか一人でも面倒をみることができれば修正が可能なソフトウェアを支持するほうが有益です
-# It is better to support software that can be fixed if just one person out of millions cares enough
 === 可能なかぎりオープンソースのソフトウェアを使う ===
@@ 32行目: / 35行目: @@
 === Keep it simple ===
+オリジナルのバージョンを購入して使用するのと比べてパッケージ化するために複雑な作業やハックが必要な場合、簡単なほうの方法を使ってください。
-If the packaging of some program requires more effort and hacks than buying and using the original version - do the simplest thing, it is Arch!
 == パッケージの命名 ==
+勝手に名前を付ける前に、パッケージ化したいソフトウェアが AUR に既に存在しないか検索してください。パッケージが存在する場合、それらの命名規則に従うようにしてください (例えば {{AUR|aquaria-hib}}, {{AUR|penumbra-overture-hib}}, {{AUR|uplink-hib}} というパッケージが存在するのに ''gish-hb'' という名前のパッケージを作成するのは止めてください)。ソースベースのパッケージが絶対に存在しないという確信がないかぎり、必ず {{Ic|-bin}} をパッケージの後ろに付けてください。
-Before choosing a name on your own, search in AUR for existing versions of the software you want to package. Try to use established naming conversion (e.g. do not create something like {{AUR|gish-hb}}{{Broken package link|{{aur-mirror|gish-hb}}}} when there are already {{AUR|aquaria-hib}}, {{AUR|penumbra-overture-hib}} and {{AUR|uplink-hib}}). Use suffix {{Ic|-bin}} '''always''' unless you are sure there will never be a source-based package&mdash;its creator would have to ask you (or in worst case TUs) to orphan existing package for him and you both will end up with PKGBUILDs cluttered with additional {{Ic|replaces}} and {{Ic|conflicts}}.
 == ファイルの置き場所 ==
+既存のパッケージを解析して、ファイルが衝突しないように注意してください。パッケージディレクトリの所有権を {{Ic|root:games}} にするような汚いハックを使う必要がないのであれば、ファイルを {{Ic|/opt}} には配置しないでください。
-Again, analyze existing packages (if present) and decide whether or not you want to conflict with them. Do not place things under {{Ic|/opt}} unless you want to use some ugly hacks like giving ownership {{Ic|root:games}} to the package directory (so users in group {{Ic|games}} running the game can write files in the game's own folder).
 == 欠けているファイル ==
@@ 47行目: / 50行目: @@
 ::必要なファイルを {{Ic|sources}} 配列に追加:
 ::{{Bc|1=sources=(... "''originalname''::'''file://'''''originalname''")}}
+::AUR ウェブインターフェイスのファイルリンクはソース tarball に含まれているファイルの名前とは異なるようになります。
-::This way the link to file in AUR web interface will look different from names of files included in source tarball.
 ::パッケージのページに以下のようなコメントを残してください:
 ::{{bc|Need archive/installer to work.}}
@@ 56行目: / 59行目: @@
 * ファイルを取得する方法が複数存在する場合:
+:{{Ic|build}} の中でディスクからファイルをコピーしたり、ネットからファイルをダウンロードしたり圧縮ファイルから展開することは良いアイデアに思えるかもしれませんが非推奨です。ユーザーの利便性を損なう可能性があり、パッケージのインストールをするときにユーザーの操作が必要になるためです。インストーラスクリプトと {{Ic|.install}} ファイルを使ってください。
-:Copying files from disk / downloading from Net / getting from archive during {{Ic|build}} phase may look like a good idea but it is not recommended because it limits the user's possibilities and :makes package installation interactive (which is generally discouraged and just annoying). Again, a good installer script and {{Ic|.install}} file can work instead.
+パッケージに必要なファイルを取得するための様々な手段の例:
-Few examples of various strategies for obtaining files required for package:
-* {{AUR|worldofgoo}} &ndash; dependency on user-provided file
+* {{AUR|worldofgoo}} &ndash; ユーザーが提供するファイルに依存
-* {{AUR|umineko-en}}{{Broken package link|{{aur-mirror|umineko-en}}}} &ndash; combining files from freely available patch and user-provided compact-disk
+* {{AUR|umineko-en}}{{Broken package link|{{aur-mirror|umineko-en}}}} &ndash; フリーなパッチとユーザーが提供するコンパクトディスクのファイルを混ぜ合わせる
-* {{AUR|worldofgoo-demo}}{{Broken package link|{{aur-mirror|worldofgoo-demo}}}} &ndash; autonomic fetching installer during build phase
+* {{AUR|worldofgoo-demo}}{{Broken package link|{{aur-mirror|worldofgoo-demo}}}} &ndash; ビルド時にインストーラを自動取得
-* {{AUR|ut2004-anthology}}{{Broken package link|{{aur-mirror|ut2004-anthology}}}} &ndash; searching for disk via mountpoints
+* {{AUR|ut2004-anthology}}{{Broken package link|{{aur-mirror|ut2004-anthology}}}} &ndash; マウントポイントでディスクを検索
 == 高度なトピック ==
 === カスタム DLAGENTS ===
-ソフトウェアによっては自動ダウンロードからソフトウェアが積極的に保護されている場合もあります: 特定の "User-Agent" 文字列のアクセスを拒否したり、ファイルの一時リンクを作成することなどが挙げられます。そういった場合でも、PKGBUILD で {{Ic|DLAGENTS}} 変数を使うことでファイルを楽にダウンロードすることができます ({{Ic|man makepkg.conf}} を参照)。{{Pkg|ttf-baekmuk}} など、[[公式リポジトリ]]のパッケージでも使われているものがあります。
+ソフトウェアによっては自動ダウンロードからソフトウェアが積極的に保護されている場合もあります: 特定の "User-Agent" 文字列のアクセスを拒否したり、ファイルの一時リンクを作成することなどが挙げられます。そういった場合でも、PKGBUILD で {{Ic|DLAGENTS}} 変数を使うことでファイルを楽にダウンロードすることができます ({{man|5|makepkg.conf}} を参照)。{{Pkg|ttf-baekmuk}} など、[[公式リポジトリ]]のパッケージでも使われているものがあります。
 ユーザーエージェント文字列をカスタマイズする場合、空白や括弧、スラッシュが含まれていると動作しなくなります。Bash の制限のため解決方法はありません。例えば以下の例は機能しません:
@@ 92行目: / 95行目: @@
 === .desktop ファイル用のアイコンの取得 ===
-プロプライエタリなソフトウェアはアイコンファイルを用意してないことが少なくなく、[[デスクトップエントリ|.desktop]] ファイルを作成するときに使えるアイコンがないことがあります。{{Pkg|icoutils}} パッケージに含まれているプログラムを使うことで実行ファイルから {{Ic|.ico}} ファイルは簡単に抽出できます。{{Ic|build}} 関数の中で抽出をすることもできます ({{AUR|sugarsdelight}}{{Broken package link|{{aur-mirror|sugarsdelight}}}} の例を参照)。
+プロプライエタリなソフトウェアはアイコンファイルを用意してないことが少なくなく、[[デスクトップエントリ|.desktop]] ファイルを作成するときに使えるアイコンがないことがあります。{{Pkg|icoutils}} パッケージに含まれているプログラムを使うことで実行ファイルから {{Ic|.ico}} ファイルは簡単に抽出できます。{{Ic|build}} 関数の中で抽出をすることもできます:
+ $ wrestool -x --output=''icon.ico'' -t14 ''executable.exe''