オープンソースのコードをめぐっては、 誰かがそれを移植し、使用し、開発に協力することを妨げることのないよう、 数多くの伝統ある良き慣習が存在しています。 それらの慣例のいくつかは Unix および Linux の世界で 伝統的に受け継がれてきたものです。 その他の慣例は、 World Wide Web のような特徴ある新しい技術やツールに関連して、 最近になって生み出されたものです。
この文書は正しい慣習について知るための一助となるでしょう。 各章の見出しには、 それぞれがチェックリストの項目となるように要旨をまとめました。 あなたの配布物が旅に出る前の点検項目とお考え下さい。
この文書は毎月 comp.os.linux.answers
に投稿されます。
また metalab.unc.edu
の pub/Linux/docs/HOWTO
を含め、
数多くの Linux FTP サイトに保管されています。
また、この HOWTO の最新の版を World Wide Web では http://metalab.unc.edu/LDP/HOWTO/Software-Release-Practice-HOWTO.html で読むことができます。
この HOWTO に関する質問や意見は Eric S. Raymond, esr@snark.thyrsus.com 宛にお気軽にお寄せ下さい。
この HOWTO の日本語版は http://www.linux.or.jp/JF/JFdocs/Software-Release-Practice-HOWTO.html で最新のものを読むことができます。 訳文に関する質問や意見は JF@linux.or.jp 宛にお寄せ下さい。
なお、翻訳文には JF Project の以下の方々の意見・校正が反映されています。
Metalab や PSA そして CPAN のような アーカイヴサイトの管理者にかかる負担が増えるにつれて、 登録作業の一部あるいは全てをプログラムによって処理するという傾向に なってきています (つまり、人間によって行われるのではないということです)。
これによって プロジェクトとアーカイヴファイルの名称が、 計算機のプログラムによって解析し理解されるよう、 正しい形式で名前付けされていることの重要性が増しました。
もし全てのアーカイヴのファイルに GNU のような名前付け -- つまり小文字のアルファベットから成る基本名称を頭に付けて、 ダッシュ (-) を付加し、続けてバージョン数字列、拡張子、 その他の識別子を付けるやり方 -- がされていたら、 これは誰の目にもわかりやすいものになります。
仮に `foobar' という名前で呼ばれているプロジェクトの、 バージョン 1、リリース 1、パッチレベル 3 があるとしましょう。 もしそれが単一のアーカイヴとして成立しているなら (おそらくは ソースコードでしょう)、以下のような名前付けがいいでしょう:
ソースアーカイヴ
LSM ファイル (Metalab に登録する場合).
次のようなのは ダメ です:
これは多くのプログラムに `foobar123' という名の プロジェクトのバージョン番号のないアーカイヴと見なされてしまいます。
これは多くのプログラムに `foobar1' という名の プロジェクトのバージョン 2.3 のアーカイヴと見なされてしまいます。
多くのプログラムはこいつを `foobar-v1' という名のプロジェクトだと解釈されてしまいます。
アンダースコアは人間が喋りにくいし、 入力しづらいし、覚えにくいです。
小賢しい利己主義者と思われても 構わない ならば。 おまけにこれは喋りにくいし、入力しづらいし、覚えにくいです。
ファイル名によってソースとバイナリアーカイヴや、 異なる種類のバイナリを区別したり、 ビルドの時のオプションのたぐいを表現する必要があるなら、 それらはバージョン番号の後に付加するファイル識別子として 取り扱うようにしてください。つまり、以下のような方法です:
ソースコード
バイナリ (タイプは不明)
ELF バイナリ
静的にリンクされた ELF バイナリ
SPARC 向けバイナリ
`foobar-ELF-1.2.3.tar.gz' みたいなのはやめましょう。 これはプログラムが基本名称から内部識別子 (`-ELF' のような部分) を 導き出しにくくなるからです。
よい名前の一般的形式は、以下のような部分から順番に成り立っています:
-
).
)
プロジェクトやコミュニティによっては、 名前付けとバージョン番号について明確に定義された慣習があり、 その場合は上記のアドバイスにならう必要はありません。 たとえば Apache のモジュールには mod_foo のような名前が一般的に使われており、 それ自身のバージョン番号とそれが動作する Apache のバージョン番号の両方が 付加されています。 同様に Perl のモジュールには浮動小数点として取り扱い可能なバージョン番号 が付けられていて (たとえば 1.3.3 のような形式よりも 1.303 のような形式を 見ることが多いでしょう)、Foo::Bar というモジュールのバージョン 1.303 の 配布物には、Foo-Bar-1.303.tar.gz という名称が付けられることが一般的です。
コミュニティと開発集団に独自の慣習を調べ、それを大切にしてください。
基本名称はプロジェクトのファイル全体を通して共通のものとし、
それは読みやすく、入力しやすく、そして覚えやすいものにするべきです。
アンダースコア(_
)を使うのはやめましょう。
それと、格段の理由のない限り、
全体あるいは一部にでも大文字を使うのはやめましょう。
人間の目視による自然な検索順序を困惑させることになりますし、
まるで小賢しく立ち振舞おうとする下衆な利己主義者みたいじゃないですか。
ふたつの異なるプロジェクトが同じ基本名称を持つと、みんなが混乱します。 はじめてのリリースの前には名前が衝突してないかをチェックしましょう。 このチェックには index file of Metalab が便利です。
ここで触れる話題のほとんどは、Linux 圏のみならず、 他の Unix も含めた移植性の確保に関係するものです。 他の Unix へ移植可能であるということは、 プロフェッショナリズムとハッカー主義の美徳であるだけでなく、 将来において Linux 自体に変化が起きた場合にそなえた 貴重な保険ということもできます。
結論から言えば、誰かがあなたのコードを Linux 以外のシステムにおいて ビルドしようとするのは明らかです。 移植性を高めておけば、あなたが受け取る煩わしくて面倒な email の数を 減らすことができるでしょう。
移植性と安定性のために、ANSI C もしくは可搬性の保証されているスクリプト言語を 使いましょう。 プラットフォームを越えて単一の実装が存在しているからです。
これに適合するスクリプト言語としては、 Python, Perl, Tcl, そして Emacs Lisp などがあります。 プレインな古い shell は不合格です。 微妙な違いのある、たくさんの異なる実装が存在していますし、 エイリアスのようなユーザカスタマイズによって、 shell の実行環境が ごちゃごちゃになっていることも想定されるからです。
Java は可搬性の高い言語であることを約束していますが、 今のところ Linux で利用できる実装は完全ではなく、 Linux との親和性も貧弱です。 Java は成熟するに連れてさらに人気を増していくように見えますが、 現時点ではまだ薄氷を踏むような選択と言えます。
C 言語で開発しているなら、ANSI で用意されたすべての機能を 好きなように使ってください。モジュール間の矛盾を洗い出すために 便利なファンクション・プロトタイプもこれに含まれます。 旧式の K&R コンパイラはすでに歴史の遺物です。
その一方で、たとえば `-pipe' オプションやネストされた関数構造など、 GCC 固有の機能が使えると仮定してはいけません。 誰かが Linux 以外、GCC 以外のシステムに移植する際に、 この問題が付きまとい、困らせることになります。
C 言語で開発しているなら、システムの環境設定を探査したり、 makefile を仕立てたりといった、可搬性にまつわる事柄を操作するために、 autoconf/automake/autoheader ユーティリティーを使いましょう。 今日では、ソースからビルドする際に、 "configure; make" とタイプして、きれいに -- 文字通り きれいに作り上げられることを人々は期待しているのです。
C 言語で開発している場合は、 リリースの前に少なくとも一回は -Wall オプションを付けてテストコンパイルを行い、 エラーが出ないことを確認しましょう。 これは非常に多くのエラーを検出します。 究極を目指すなら、-pedantic オプションを付けてコンパイルしてみましょう。
Perl で書いている場合は、コードに -c (場合によっては -T) オプションを付けて チェックしてみましょう。信心深く行うなら perl -w と `use strict' ですね (これについては Perl のドキュメントを参照してください)。
これから述べるガイドラインでは、誰かが配布物をダウンロードし、中身を取り出して 展開した際に、配布物はどのように現れるべきか、という事を説明します。
開発の初心者が冒しやすい誤りの中で、もっともわずらわしいものは、 配布物中のファイルとディレクトリをカレントディレクトリにぶちまけ、 すでにそこにあるファイル群を上書きする可能性のある tarball を作ってしまう、というものです。 こうしては絶対にいけません!
これを避けるには、アーカイヴされたファイルを全てプロジェクト名で始まる 専用のディレクトリに入れれば、現在のディレクトリの直下 にある、単一のトップ・ディレクトリの中に展開されるでしょう。
これを完璧に行うための makefile の裏技があります。 配布物のディレクトリが `foobar' という名前で、 SRC という変数には配布ファイルのリストが入っているとします。 これには GNU tar 1.13 が必要です。
VERS=1.0 foobar-$(VERS).tar.gz: tar --name-prefix='foobar-$(VERS)/' -czf foobar-$(VERS).tar.gz $(SRC)
もし古い tar を使っている場合は、以下のようにします。
foobar-$(VERS).tar.gz: @ls $(SRC) | sed s:^:foobar-$(VERS)/: >MANIFEST @(cd ..; ln -s foobar foobar-$(VERS)) (cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`) @(cd ..; rm foobar-$(VERS))
ソース配布物のロードマップとなる README もしくは READ.ME というファイルを 用意しましょう。古来の言い伝えでは、これはソースを展開した勇敢なる探検者たちが 最初に目にして読むはずの書、ということになっています。
README の中に書いておきたい項目は:
README ファイルを読むより先に、 勇敢なる探検者たちは展開した 配布物のトップディレクトリのファイル名を探索するでしょう。 ファイルの名称は、それ自体が情報を含んでいます。 標準的な名前付けの慣例を踏襲することによって、 次に何を見るべきなのかという重要な手がかりを、探検者たちに示すことができます。
標準的なトップレベルのファイル名とそれが意味するものについて説明しましょう。 配布物にこれら全部が必要ではありません。
最初に読む案内書
設定・ビルド・インストール方法の解説
プロジェクトに対する貢献者のリスト
プロジェクトに関する最近のニュース
プロジェクトの履歴
プロジェクトのライセンス (GNU 流の慣習)
プロジェクトのライセンス
配布物に含まれるファイルの一覧
プロジェクトに関して、よく尋ねられる質問とその回答を記したプレインテキストのドキュメント
Emacs や vi で利用するタグファイル
これらのファイル名が全て大文字で構成されているという慣習は、 それらがビルドの部品として使われるのではなく、 パッケージに関する一般的情報を含んだ人間が読むべきものだと 暗示していることに注意してください。
あなたのソフトウェアは、 その存在を知られない限り世界に貢献することはできません。 また、プロジェクトの存在をインターネット上で明らかにすることは、 ユーザを増やしたり共同開発者を募るのに役立つでしょう。 これについての標準的な手法に関して解説します。
comp.os.linux.announce で新たなリリースのお知らせをしましょう。
それ自体がよく購読されている Newsgroup である上に、 Freshmeat のような Web ベースで新着情報を扱うサイトへも転送されています。
あなたのアプリケーションに直接関連する USENET の Newsgroup を見つけて、 そこでもアナウンスしましょう。 慎みを持って、 ソフトウェアとしての機能が関係する Newsgroup にのみ投稿してください。
例えば IMAP サーバに問い合わせを行う Perl で書かれたプログラムを リリースしようとしているなら、 間違いなく comp.mail.imap には投稿するべきでしょう。 しかしプログラムが Perl の先鋭的テクニックのお手本にもなるものでなければ、 おそらく comp.lang.perl には投稿しない方がよいでしょう。
アナウンスにはプロジェクトの Web サイトの URL も示しておきましょう。
(訳注: 日本語の Newsgroup では
fj.sources
でソフトウェア公開のアナウンスがされています。
本来テキストエンコードされたソースコードのアーカイブを、
直接投稿する Newsgroup でしたが、
最近はアナウンスのみを投稿することの方が増えています。
投稿する記事には Followup-To:
ヘッダで
fj.sources.d
を指定することがマナーとなっています。)
プロジェクトのユーザあるいは開発者のコミュニティを しっかりと築くことを目指すならば、 Web サイトを用意した方がよいでしょう。 Web サイトに用意する標準的な内容は以下のようなものです:
プロジェクトのサイトによっては、 一次ソースツリーへの匿名アクセスが可能な URL を用意することもあります。
開発の協力者が交流を行い、パッチを交換できるような非公開のメーリングリストを 用意することが一般によく行われています。 プロジェクトの進歩状況を知らせて欲しい人々を対象とした、アナウンスのための メーリングリストがあってもよいでしょう。
ここ数年の間、 Metalab archive は Linux のソフトウェアのための重要な拠点となってきました。
それ以外に以下のような重要なサイトがあります:
インストールに使われるバイナリパッケージの事実上の標準フォーマットは、 Red Hat Package Manager, RPM です。 これはもっとも人気のある Linux ディストリビューションの特長となっており、 事実上 (Debian と Slackware を除いた) 他の Linux ディストリビューションでも サポートされています。
したがって、ソースコードの tarball と同様に、 インストール可能な RPM 形式のファイルを プロジェクトのサイトで提供するのも良い考えでしょう。