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

提供: ArchWiki
2017年3月15日 (水) 00:28時点におけるKusakata (トーク | 投稿記録)による版 (同期)
ナビゲーションに移動 検索に移動
パッケージ作成ガイドライン

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 パッケージガイドラインを見てください。

根拠

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

  • インストールやアンインストールの平易化
This is applicable even to the simplest of apps, which consist of a single script to be installed into /usr/bin. Instead of issuing:
$ chmod +x filename
# cp filename /usr/bin/
you can type just
# makepkg -i
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.
  • pacman の機能の利用
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.
  • コードや知識の共有
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.

一般的なルール

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

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

  1. フリーでないソフトウェアのパッケージングは面倒であり大抵 The Arch Way に反しています
  2. 一企業によって所有されているソフトウェアよりも全員で共有しているソフトウェアを支援したほうが有益です
  3. 活発に開発されているソフトウェアを支援したほうが有益です
  4. It is better to support software that can be fixed if just one person out of millions cares enough

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

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

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!

パッケージの命名

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 gish-hbAUR[リンク切れ: アーカイブ: aur-mirror] when there are already aquaria-hibAUR, penumbra-overture-hibAUR and uplink-hibAUR). Use suffix -bin always unless you are sure there will never be a source-based package—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 replaces and conflicts.

ファイルの置き場所

Again, analyze existing packages (if present) and decide whether or not you want to conflict with them. Do not place things under /opt unless you want to use some ugly hacks like giving ownership root:games to the package directory (so users in group games running the game can write files in the game's own folder).

欠けているファイル

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

  • ファイルを取得する方法がひとつしかない場合:
  • ソフトウェアが圧縮ファイル/インストーラーで配布されている場合:
必要なファイルを sources 配列に追加:
sources=(... "originalname::file://originalname")
This way the link to file in AUR web interface will look different from names of files included in source tarball.
パッケージのページに以下のようなコメントを残してください:
Need archive/installer to work.
そして PKGBUILD の中で詳細に説明してください。
  • ソフトウェアがコンパクトディスクで配布されている場合:
tsukihime-enAUR[リンク切れ: アーカイブ: aur-mirror] パッケージのように、インストーラースクリプトと .install ファイルを追加してください。
  • ファイルを取得する方法が複数存在する場合:
Copying files from disk / downloading from Net / getting from archive during 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 .install file can work instead.

Few examples of various strategies for obtaining files required for package:

高度なトピック

カスタム DLAGENTS

ソフトウェアによっては自動ダウンロードからソフトウェアが積極的に保護されている場合もあります: 特定の "User-Agent" 文字列のアクセスを拒否したり、ファイルの一時リンクを作成することなどが挙げられます。そういった場合でも、PKGBUILD で DLAGENTS 変数を使うことでファイルを楽にダウンロードすることができます (man makepkg.conf を参照)。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 によって復号化できることがあります。
  • innoextractAUR は Inno Setup によって作成された .exe インストーラーを解凍できます (GOG.com のゲームなどで使われています)。

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

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

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

「https://wiki.archlinux.jp/index.php?title=ノンフリーアプリケーションパッケージガイドライン&oldid=8257」から取得