[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
patch for 「Debian 新メンテナガイド」
- From: victory.deb@xxxxxxxxx
- Subject: patch for 「Debian 新メンテナガイド」
- Date: Wed, 7 Oct 2009 23:40:53 +0900
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :in-reply-to:references:x-mailer-plugin:message-id:mime-version :content-type:content-transfer-encoding:x-mailer; bh=0nVDZVNWGhoomjCxqWRr/dQT3mQd9mqlBDlkKE6PrOs=; b=q1BKVa0UIKjAGSBklSnlIKWPZaqjv2lSE/ZvCwxqXD8iuH4BateiW/1DaJ8PmQvyny Bu6brnYl+/3X0qdgFxAq75ACNm+/mzz4FQ1uEwcjrXL8gmgiHecKRbfeoTGMyEG0ZxQX /Uoj9pnmy1DAc9E4DUgj7wrOqW2BSfcLvK1ZQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:in-reply-to:references:x-mailer-plugin :message-id:mime-version:content-type:content-transfer-encoding :x-mailer; b=EmjY/uA6ZSNiIGY93RsrP/1vC4dY6quLAOdNyNDDQoDg+yxBw2VIYNGdwUTmMY0a7J URHteth3+CFf69M//HZs8Vrr3yzDMomC78cg7ofH/BgqJP439yd7j0FkDNvHyTxVMsOZ 044Px8NzZpGaeVk42xgx4ROToMJXR9ERxdPno=
- List-help: <mailto:debian-doc-ctl@debian.or.jp?body=help>
- List-id: debian-doc.debian.or.jp
- List-owner: <mailto:debian-doc-admin@debian.or.jp>
- List-post: <mailto:debian-doc@debian.or.jp>
- List-software: fml [fml 4.0.3 release (20011202/4.0.3)]
- List-unsubscribe: <mailto:debian-doc-ctl@debian.or.jp?body=unsubscribe>
- X-ml-info: If you have a question, send e-mail with the body "help" (without quotes) to the address debian-doc-ctl@debian.or.jp; help=<mailto:debian-doc-ctl@debian.or.jp?body=help>
- X-ml-name: debian-doc
- X-mlserver: fml [fml 4.0.3 release (20011202/4.0.3)]; post only (only members can post)
- X-spam-checker-version: SpamAssassin 3.1.7-deb3 (2006-10-05) on osdn.debian.or.jp
- X-spam-level:
- X-spam-status: No, score=0.0 required=10.0 tests=KI,NO_REAL_NAME,PLING_QUERY, SUBJECT_ENCODED_TWICE autolearn=disabled version=3.1.7-deb3
- References: <20090926061811.6a619fcc.henrich@debian.or.jp> <20091002071359.5B6A.C7917478@xxxxxxxxx>
- Message-id: <20091007234005.04DA.C7917478@xxxxxxxxx>
- X-mail-count: 06323
- X-mailer: Becky! ver. 2.51.07 [ja] (Unregistered)
victoryでし
> 原版のcvsにあった2002/4頃のとsvnの最新版との差分を
> テキトーに手動でマージして訳してみました。
> 行数にして半分ほど片づいた(Chapter で言えば4まで)ので一旦投げます。
svnの5358からの差分を添付します。
最新の原版と見比べて過不足補ったので抜けはないと思われます。。
--
victory
------
--- maint-guide.ja.sgml.utf8.old 2009-10-02 16:22:56.152000000 +0900
+++ maint-guide.ja.sgml 2009-10-07 23:37:21.916000000 +0900
@@ -5,9 +5,8 @@
<!ENTITY % default SYSTEM "default.ent"> %default;
]>
-<!-- CVS revision of this document "$Revision: 1.39 $" -->
-<!-- CVS revision of original english document "*.**" -->
-
+<!-- CVS revision of this document "$Revision: 1.116 $" -->
+<!-- SVN revision of original english document "5358" -->
<debiandoc>
@@ -26,10 +25,11 @@
<author> 日本語訳更新 (v1.2): 佐野武俊 <email/sano@debian.org/
</author>
- <version>version 1.2, 6 April 2002.</version>
+ <version>version 1.2.13, 5 June 2008.</version>
<copyright>
<copyrightsummary>Copyright © 1998-2002 Josip Rodin.</copyrightsummary>
+ <copyrightsummary>Copyright © 2005-2007 Osamu Aoki.</copyrightsummary>
<p>この文書は GNU 一般公有使用許諾書、バージョン 2 かそれ以降が
規定する条件の下で利用できます。
@@ -65,7 +65,6 @@
しれません。まあ、もしあなたが本当に駆け出しの Linux ユーザ
ならば困難な仕事でしょうが、でもそうだったら今ごろこんな文書
読んでませんて :-)
-
パッケージを作成するには Unix のプログラミングについてある程度
知っている必要がありますが、神様みたいに精通している必要は
全くありません。
@@ -112,8 +111,7 @@
(詳しくは <manref name="dpkg-source" section="1"> を参照)。
<item><package/file/ - この便利なプログラムを使うと
- そのファイルがどういう形式のものか判定することが
- できます
+ そのファイルがどういう形式のものか判定することができます
(詳しくは <manref name="file" section="1"> を参照)。
<item><package/gcc/ - GNU C コンパイラ。あなたのプログラムが
@@ -161,38 +159,35 @@
前処理される設定スクリプトや Makefile を利用しています。
(詳しくは「info autoconf」および「info automake」)
- <item><package/dh-make/ と <package/debhelper/ -
- dh-make はあとで説明するパッケージのひな型を用意するのに
- 必要となります。またこのひな型ではパッケージを生成する
- ために debhelper ツールをいくつか使います。
+ <item><package/dh-make/ と <package/debhelper/ - dh-make
+ はあとで説明するパッケージのひな型を用意するのに必要となります。
+ またこのひな型ではパッケージを生成するために debhelper
+ ツールをいくつか使います。
これらを使わなくてもパッケージ作成は可能ですが、
- 初めてパッケージを作る方には利用を
- <strong>強く</strong> お勧めします。
- パッケージを作るのも、以後パッケージを管理するのも
- ずっと簡単になるからです。
+ 初めてパッケージを作る方には利用を<strong>強く</strong>
+ お勧めします。パッケージを作るのも、
+ 以後パッケージを管理するのもずっと簡単になるからです。
(詳しくは <manref name="dh_make" section="1">、
<manref name="debhelper" section="1">、
/usr/share/doc/debhelper/README を参照)
- <item><package/devscripts/ - このパッケージは
- メンテナにとって便利であると思われるいくつかの
- 有用で優れたスクリプトを含んでいますが、だから
- といってパッケージを作成するために必須という
- わけではありません。
+ <item><package/devscripts/ - このパッケージはメンテナにとって
+ 便利であると思われるいくつかの有用で優れたスクリプトを
+ 含んでいますが、だからといってパッケージを作成するために
+ 必須というわけではありません。
(詳しくは /usr/share/doc/devscripts/README.gz 参照)。
<item><package/fakeroot/ - このユーティリティを使うと、
- パッケージを作成する際に何度か必要となる root 権限を
- エミュレートすることができます。
+ パッケージを作成する際に何度か必要となる root
+ 権限をエミュレートすることができます。
(詳しくは <manref name="fakeroot" section="1"> を参照)
- <item><package/gnupg/ - このツールを使うと、自分の
- パッケージに「デジタル <em>署名</em>」を付けることが
- できます。もしあなたが自分の作成したパッケージを他の
- 人々に配布したいのなら、これは特に重要です。
- また、Debian ディストリビューションにあなたの作成した
- パッケージが含まれるようになった時には、確実にこの
- デジタル署名をすることになります。
+ <item><package/gnupg/ - このツールを使うと、自分のパッケージに
+ 「デジタル <em>署名</em>」を付けることができます。もしあなたが
+ 自分の作成したパッケージを他の人々に配布したいのなら、
+ これは特に重要です。また、Debian ディストリビューションに
+ あなたの作成したパッケージが含まれるようになった時には、
+ 確実にこのデジタル署名をすることになります。
(詳しくは <manref name="gpg" section="1"> を参照)
<item><package/g77/ - GNU Fortran 77 コンパイラ。あなたの
@@ -202,15 +197,13 @@
<item><package/gpc/ - GNU Pascal コンパイラ。あなたの
プログラムが Pascal 言語で書かれている場合に必要です。
ここで注目に値するのは <package/fp-compiler/、
- Free Pascal コンパイラで、こちらもまたこの作業に適して
- います。
+ Free Pascal コンパイラで、こちらもまたこの作業に適しています。
(詳しくは <manref name="gpc" section="1"> および
<manref name="ppc386" section="1"> を参照)
- <item><package/xutils/ -
- ある種のプログラム (通常 X11 のために開発されたもの) は、
- これらのプログラムを利用して、マクロ関数の組み合わせから
- Makefile 群を生成します。
+ <item><package/xutils/ - ある種のプログラム (通常 X11
+ のために開発されたもの) は、これらのプログラムを利用して、
+ マクロ関数の組み合わせから Makefile 群を生成します。
(詳しくは <manref name="imake" section="1">、
<manref name="xmkmf" section="1"> を参照)
@@ -218,7 +211,14 @@
あなたが構築したパッケージを調べて、その中にありがちなミスが
見つかったらそれを指摘し、その問題について説明してくれます
(詳しくは <manref name="lintian" section="1">、
- /usr/share/doc/lintian/lintian.html/index.html を参照)。
+ /usr/share/doc/lintian/lintian.html/index.html を参照)
+
+ <item><package/pbuilder/ - このパッケージには chroot
+ 環境の作成や保守に使用されるプログラムが含まれます。
+ この chroot 環境下で Debian パッケージをビルドすることで
+ 適切なビルド依存の確認及び FTBFS バグの回避ができます。
+ (詳しくは <manref name="pbuilder" section="8"> 及び
+ <manref name="pdebuild" section="1"> を参照)
</list>
<p>さて、以下はこの文書と合わせて読むべき<em>とても重要</em>な
@@ -232,15 +232,15 @@
についてなどいろいろ載っていますが、
さしあたって重要なことは、ディストリビューションに含まれるために
それぞれのパッケージが満たすべき必要条件の説明です
- (詳しくは /usr/share/doc/debian-policy/policy.html/index.html を参照)。
+ (詳しくは &debian-policy; を参照)。
<item><em>developers-reference</em> - 開発者リファレンス。
例えばアーカイブの構造、パッケージ名の変更方法、
パッケージの選び方、メンテナを降りるにはどうしたらよいか、
- どうやって NMU をするか、バグとのつき合い方、
+ どうやって NMU をするか、バグとのつき合い方、best packaging practices
いつどこにアップロードすればよいかなどなど、特に技術的な事柄以外の
パッケージ化についてのありとあらゆる情報がここにあります。
- (詳しくは /usr/share/doc/developers-reference/developers-reference.html/index.html を参照)
+ (詳しくは &developers-reference; を参照)
</list>
<p>上記の簡単な説明は、それぞれのパッケージが何をするのか紹介
@@ -249,13 +249,34 @@
ください。きついと思われるかも知れませんが、あとになればきっと
<em>読んでてよかったなあ</em>と思うことでしょう。
- 注意: <package/debmake/ は dh-make と似た働きをする
+ <p>注意: <package/debmake/ は dh-make と似た働きをする
いくつかのプログラムを含むパッケージですが、現在では
このパッケージを <em>使うべきでない</em> とされているため、
この文書では <strong>説明しません</strong>。
- <package/debmake/ について詳しく知りたい人は
- <url name="Debmake マニュアル" id="http://www.debian.org/~jaldhar/";>
- を参照してください。
+
+ <sect id="debiandeveloper">正式な Debian 開発者
+
+ <p>自分のパッケージがビルドできた後(あるいはその最中でも)、
+ 正式な Debian 開発者になって新しいパッケージを次の
+ ディストリビューションに取り込むことを目指すのも良い案です
+ (そのプログラムが便利なら、ですがもちろん便利ですよね?)。
+
+ <p>一夜にして正式な Debian 開発者になることはできません。
+ これは技術的なスキルだけに留まらない何かが必要となるからです。
+ そのことでがっかりしないでください。それが他の人にとっても
+ 便利なものならメンテナとして、正式な Debian 開発者にならなくとも、
+ <url name="Debian 新規メンテナ (New Maintainer, NM) プロセス"
+ id="&nm-home;"> に応募した上で、
+ スポンサーを通してパッケージをアップロードすることは可能です。
+ ここで述べたスポンサーとは正式な Debian 開発者で、
+ メンテナがパッケージを Debian アーカイブにアップロード
+ するのを補助する人を指します。この手順に関する詳細は
+ <url id="&mentors-faq;" name="debian-mentors FAQ">
+ にあります。
+
+ <p>正式な Debian 開発者になるのに新しいパッケージの作成は
+ 必須ではないことに注意してください。既存のパッケージに対して
+ 貢献していくことでも正式な Debian 開発者への道は開かれます。
<sect id="otherinfo">その他知っておくべきこと
@@ -271,57 +292,42 @@
作る人を示し、「上流作者(upstream author)」とはプログラムそれ自身を
作った人を指します。そして「上流メンテナ(upstream maintainer)」
というのは Debian の外部で現在プログラムそのものを管理している人の
- ことです。
- たいていの場合、作者と上流メンテナは同一人物ですが、メンテナすらも
- 同じという場合もあり得ます。
+ ことです。たいていの場合、作者と上流メンテナは同一人物ですが、
+ メンテナすらも同じという場合もあり得ます。
もしあなたが何かのプログラムを書いて、それを Debian に入れたいと
考えたならば、Debian プロジェクトに参加してメンテナになってください。
- <p>もしディストリビューションの次のリリースにあなたのプログラムを
- 含めたい(そのプログラムが有用なら、ぜひ!)ならば、パッケージを
- 構築したあとに(あるいはしている最中でも構いませんが)
- 正式な Debian メンテナになる必要があります。その手続きは
- 開発者リファレンスで説明されていますので、そちらを参照してください。
-
<chapt id="first">はじめの一歩
<sect id="choose">パッケージ化するプログラムの選定
<p>パッケージにしたいプログラムについてはすでに各自お考えがあると
- 思います。まず最初にしなければならないことは、そのパッケージが
- すでにディストリビューションに収録されていないかどうか確認することです。
- もしあなたが「安定版」を使っているのなら、
- たぶん
+ 思います。まず最初にしなければならないことは、
+ そのパッケージがすでにディストリビューションに収録されていないか
+ <prgn>aptitude</prgn> を使ってどうか確認することです。
+ もしあなたが「安定版」を使っているのなら、たぶん
<url name="パッケージ検索ページ" id="http://www.debian.org/distrib/packages";>
に行って調べるのが最上の策です。
- ((訳注: <url name="Debian JP パッケージ" id="http://www.debian.or.jp/Packages.html";>
+ ((訳注: <url name="Debian JP パッケージ"
+ id="http://www.debian.or.jp/Packages.html";>
もついでに見ておくといいかもしれません。))
- もしあなたが<strong>現在の</strong>「開発版」ディストリビューションを使って
- いるのなら、以下のコマンドを使って調べてみてください。
-
- <example>
- dpkg -s プログラム名
- dpkg -l '*プログラム名*'
- </example>
<p>もしパッケージが既に存在していたら、インストールしましょう！ :-)
- もしそのパッケージが「みなし子」にされていたら (もしメンテナの名前が
+ もしそのパッケージが「みなしご」にされていたら (もしメンテナの名前が
「Debian QA Group」になっていたら)、そのパッケージを引き取ることが
できるかもしれません。
- <url name="みなしごにされたパッケージ"
- id="http://www.debian.org/devel/wnpp/orphaned";>
- および
- <url name="引き取り手を探しているパッケージ"
- id="http://www.debian.org/devel/wnpp/rfa_bypackage";>
- を調べて、本当にそのパッケージが引き取ってくれるメンテナを
- 待っている状態なのかどうか、確認してください。
+
+ <p>その場合、Debian ウェブサイト
+ <url name="作業が望まれるパッケージ (WNPP)"
+ id="http://www.debian.org/devel/wnpp/";>
+ とそのリンク先を見て最新の「養子/みなしご」状態を確認してください。
<p>もしパッケージを引き取ることができたら、
- (<tt/apt-get source パッケージ名/ などの方法で)
- ソースを入手して、調べてみてください。
- 残念ながらこの文書ではパッケージを引き取ることについて
- わかりやすく説明してはいません。ありがたいことに、既に
- 誰かがあなたのためにパッケージを準備してくれたわけですから、
+ (<tt/apt-get source パッケージ名/ などの方法で) ソースを入手して、
+ 調べてみてください。残念ながらこの文書ではパッケージを
+ 引き取ることについてわかりやすく説明してはいません。
+ ありがたいことに、
+ 既に誰かがあなたのためにパッケージを準備してくれたわけですから、
そのパッケージがどのように動作するのか理解することはそれほど
難しくはないでしょう。
とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスは
@@ -342,28 +348,35 @@
ください。もしその必要が無ければ、まだ誰も手をつけていない
他の面白いプログラムを探して再チャレンジです。</item>
- <item>プログラムはライセンスを<strong>与えられていなければなりません</strong>。
- そのライセンスが
- <url name="Debian フリーソフトウェアガイドライン、DFSG"
- id="http://www.debian.org/social_contract#guidelines";>
- に示された基準を満たす「フリー」なものであれば言うことなしです。
+ <item>プログラムはライセンスを
+ <strong>与えられていなければなりません</strong>。
+ <list>
+ <item><tt>main</tt> に分類されるものについては、Debian
+ ポリシーの規定により、<url name="Debian フリーソフトウェアガイドライン"
+ id="http://www.debian.org/social_contract#guidelines";>(DFSG)
+ に完全に準拠しなければならず、そのコンパイルや実行に際して
+ <tt>main</tt> 以外にあるパッケージを必要とすることは
+ <strong>許されません</strong>。これは好ましい例です。</item>
+ <item><tt>contrib</tt> に分類されるものについては、
+ DSFG に完全に準拠<strong>しなければなりません</strong>が、
+ そのコンパイルや実行に際して、
+ <tt>main</tt> 以外にあるパッケージを必要とすることが許容されます。
+ </item>
+ <item><tt>non-free</tt> に分類されるものについては、
+ DSFG に準拠<strong>しない</strong>部分があっても許容されますが、
+ 配布可能であることは<strong>必須</strong>です。</item>
((訳注: 日本のミラーサイトは
- <url name="Debian フリーソフトウェアガイドライン" id="http://www.jp.debian.org/social_contract#guidelines";>
+ <url name="Debian フリーソフトウェアガイドライン"
+ id="http://www.jp.debian.org/social_contract#guidelines";>
にあります))
-
- もしガイドラインにそぐわない点があっても、ライセンスが
- プログラムの配布を許可している場合には、Debian の「contrib」や
- 「non-free」のセクションに含めることができます。
- もしどのセクションに入れるべきか迷ったら、
+ もしどのセクションこに入れるべきか迷ったら、
<email/debian-legal@list.debian.org/ で聞いてみてください。
</item>
<item>動作のために setuid root が必要なプログラムを
パッケージ作成の最初の練習問題として選ぶべきでは
- <strong>ありません</strong>。
-
- さらに言えば、すべての場面において setuid や setgid でさえも
- 必要とすべきではありません。</item>
+ <strong>ありません</strong>。さらに言えば、すべての場面において
+ setuid や setgid でさえも必要とすべきではありません。</item>
<item>デーモンとして動作するプログラムや、システム管理者の
ための専用のコマンド (*/sbin ディレクトリに含まれるもの)、
@@ -372,8 +385,7 @@
</item>
<item>バイナリ実行形式として使えるプログラムを選びましょう。
- ライブラリをパッケージ化するのはずっと難しいのです。
- </item>
+ ライブラリをパッケージ化するのはずっと難しいのです。</item>
<item>ちゃんとした説明書きのあること。あるいは理解可能な
ソースコードであること (つまり、コードに書かれた処理の流れが
@@ -382,8 +394,7 @@
<item>プログラムの作者に連絡をとってパッケージ化の承諾をもらいましょう。
何かプログラムそのものに起因する問題が発生した際に、作者にいろいろ聞けると
いうことは重要なので、由来のはっきりしないソフトウェアの断片をパッケージ化
- するのはやめておきましょう。
- </item>
+ するのはやめておきましょう。</item>
<item>そして最後に、といってもこれが重要なのですが、
ちゃんと動くかどうか確かめましょう。そして何回か試してみましょう。
@@ -391,14 +402,13 @@
</list>
<p>もちろんこれらのことは安全策というだけのことです。筆者としては、
- 何も知らないままにパッケージ化しておまけにミスった
- ある種の setuid デーモンのせいで
- 怒り狂ったユーザからあなたに向けて抗議殺到というような事態を
- 回避したいのです。
- パッケージ化についてもっと経験を積めば、こうしたパッケージも
- 作れるようになるでしょう。しかし、どんなに老練な開発者だって
- 何か分からないことがあれば debian-mentors メーリングリストで
- 質問するのです。そこには喜んで手助けしてくれる人々がいます。
+ 何も知らないままにパッケージ化しておまけにミスったある種の setuid
+ デーモンのせいで怒り狂ったユーザからあなたに向けて抗議殺到
+ というような事態を回避したいのです。パッケージ化について
+ もっと経験を積めば、こうしたパッケージも作れるようになるでしょう。
+ しかし、どんなに老練な開発者だって何か分からないことがあれば
+ debian-mentors メーリングリストで質問するのです。
+ そこには喜んで手助けしてくれる人々がいます。
<p>もっと詳しい話は、開発者リファレンスに載っていますので
そちらを参照してください。
@@ -424,8 +434,8 @@
注意してください。
<p> 自分のホームディレクトリ以下に 'debian'、'deb'、または何か適当だと
- 思われる名前のサブディレクトリを作りましょう (今回の場合には ~/gentoo/
- としても良いでしょう)。
+ 思われる名前のサブディレクトリを作りましょう (今回の場合には
+ </file>~/gentoo/</file> としても良いでしょう)。
ダウンロードしたアーカイブをここにコピーし、
「tar xzf gentoo-0.9.12.tar.gz」を実行して展開してください。
この時 (一見「無関係」に思えるようなものも含めて) エラーは一切
@@ -437,16 +447,14 @@
<p>さて、「gentoo-0.9.12」という別のサブディレクトリができました。
展開したディレクトリに移って、提供されているドキュメントを
<strong>徹底的に</strong>読みましょう。
- 通常は README*、INSTALL*、*.lsm、*.html などといった名前の
- ファイルがあり、
+ 通常は README*、INSTALL*、*.lsm、*.html などといった名前のファイルがあり、
それらの文書の中に、どうやったら正しくコンパイルできるのか、
どうインストールすればよいのかといった情報が見つかるはずです。
- (たぶん /usr/local/bin にインストールするものとして説明されています
-が、
- そうしてはいけません。これについては <ref id="destdir"> を
- 参照してください)。
+ (たぶん /usr/local/bin にインストールするものとして説明されていますが、
+ そうしてはいけません。
+ これについては <ref id="destdir"> を参照してください)。
- <p>プログラムによって構築の手順は代わりますが、最近のプログラムだと
+ <p>プログラムによって構築の手順は変わりますが、最近のプログラムだと
「configure」スクリプトが付属していることがあります。
このスクリプトはソースをあなたのシステムに合わせて設定し、
このままコンパイルできるかどうかをチェックします。
@@ -523,46 +531,66 @@
その後、画面に表示される情報をよく読み、確認したら <enter> を押して
ください。
- <p>初めてパッケージを作るというときには、マルチバイナリパッケージや
- ライブラリに手を出さない方が無難です。この話は前にもしましたね。
+ <p>この <prgn>dh_make</prgn> の実行後、上流の tarball
+ の複製が親ディレクトリに <file>gentoo_0.9.12.orig.tar.gz</file>
+ といった名前で生成され、<file>diff.gz</file> と合わせて
+ non-native Debian ソースパッケージの作成に対応します。
+ このファイル名には 2 つの特徴があることに注目してください。
+ <list compact>
+ <item>パッケージ名とバージョン番号は "<tt>_</tt>" で区切られる。
+ <item>"<tt>orig.</tt>" が "<tt>tar.gz</tt>" の前に付く。
+ </list>
+
+ <p>初めてパッケージを作るというときには、複雑なパッケージ、つまり
+ <list compact>
+ <item>マルチバイナリパッケージ
+ <item>ライブラリ
+ <item>ソースファイルの形式が <tt>tar.gz.</tt> でも
+ <tt>tar.bz2</tt> でもないもの
+ <item>ソース tarball に配布不可能なものが含まれる場合
+ </list>
+ には手を出さない方が無難です。この話は前にもしましたね。
実際には作業自体はそれほど大変ではないのですが、ちょっとだけ
より多くの知識が必要になります。そのため、ここではその作業について
一切説明しません。
- <p>dh_make の実行は <strong>ただ一度だけ</strong> です。注意して
- ください。既に「Debian 化」された同じディレクトリで再び実行すると、
- 正しく動作しないでしょう。これはつまり、将来パッケージの改訂版や
- 新バージョンをリリースする時には別の方法を使うことになる、という
- ことでもあります。パッケージの更新作業についての詳細は後で説明する
- <ref id="update"> の部分を読んでください。
+ <p><prgn>dh_make</prgn> の実行は <strong>ただ一度だけ</strong>
+ です。注意してください。既に「Debian 化」された同じディレクトリで
+ 再び実行すると正しく動作しないでしょう。これはつまり、
+ 将来パッケージの改訂版や新バージョンをリリースする時には
+ 別の方法を使うことになる、ということでもあります。
+ パッケージの更新作業についての詳細は後で説明する <ref id="update">
+ の部分を読んでください。
<chapt id="modify">ソースコードの変更
- <p>ふつう、プログラムは自分自身を /usr/local 以下のディレクトリに
- インストールするようになっています。しかし、Debian システムにおいては、
- /usr/local 以下はシステム管理者(とユーザ)の個人的利用のために
- 予約されているので、Debian パッケージはこのディレクトリを使っては
- いけないことになっています。
- このため、(通常は Makefile に始まる) プログラムを生成するための
- 仕組を調べる必要があります。
- Makefile というのは <manref name="make" section="1"> がこのプログラムを
- 自動生成するために利用するスクリプトです。
+ <p>ふつう、プログラムは自分自身を /usr/local
+ 以下のディレクトリにインストールするようになっています。しかし、
+ Debian システムにおいては、/usr/local 以下はシステム管理者
+ (とユーザ)の個人的利用のために予約されているので、Debian
+ パッケージはこのディレクトリを使ってはいけないことになっています。
+ このため、(通常は Makefile に始まる)
+ プログラムを生成するための仕組を調べる必要があります。
+ Makefile というのは <manref name="make" section="1">
+ がこのプログラムを自動生成するために利用するスクリプトです。
Makefile についての詳細は、<ref id="rules">を参照してください。
- <p>もしあなたのプログラムが GNU <manref name="automake" section="1"> や
- <manref name="autoconf" section="1"> を使っているのでしたら、ソースに
- それぞれ Makefile.am や Makefile.in などのファイルが含まれているはずです。
- このような場合には、Makefile ではなく、これらのファイルを変更する必要が
- あります。何故なら、automake を実行すると Makefile.am から生成された
- 情報によって Makefile.in が上書きされ、また ./configure を実行すると
- Makefile.in から生成した情報によって Makefile が上書きされるからです。
+ <p>もしあなたのプログラムが GNU <manref name="automake"
+ section="1"> や <manref name="autoconf" section="1">
+ を使っているのでしたら、ソースにそれぞれ Makefile.am や Makefile.in
+ などのファイルが含まれているはずです。このような場合には、Makefile
+ ではなく、これらのファイルを変更する必要があります。何故なら、
+ automake を実行すると Makefile.am から生成された情報によって
+ Makefile.in が上書きされ、また ./configure を実行すると Makefile.in
+ から生成した情報によって Makefile が上書きされるからです。
Makefile.am の編集には、automake の知識がすこしばかり必要になります。
これについては info automake で調べることができます。
一方、Makefile.in の編集は普通の Makefile の編集とほぼ同じです。
ただちょっと変数に気をつければいいだけです。変数というのは例えば
@CFLAGS@ や @LN_S@ などのように「@」で囲まれた文字列のことです。
これらの変数は ./configure を実行した際に実際の内容に置き換えられます。
-
+ 次に進む前に必ず <file>&autotools-dev;</file> を読んでください。
+
<p>修正の具体的なやり方について<em>何から何まで</em>説明するにはとても
紙面が足りませんが、よくあるパターンとしては大体以下のようなものでしょう。
@@ -624,8 +652,8 @@
ICONS = /usr/local/share/gentoo
</example>
- <p>オリジナルの設定では、それぞれのファイルを <file>/usr/local</file> 以下に
- インストールするようになっていることがわかります。
+ <p>オリジナルの設定では、それぞれのファイルを <file>/usr/local</file>
+ 以下にインストールするようになっていることがわかります。
これらのパスを以下のように変更してください：
<p><example>
@@ -638,15 +666,16 @@
<p>しかしなぜこのディレクトリなんでしょう。他の所じゃだめでしょうか？
だめです。
- なぜなら Debian パッケージの場合、<file>/usr/local</file> 以下へファイルを
- インストールすることは絶対に無いと決まっているからです。このディレクトリ
+ なぜなら Debian パッケージの場合、ファイルを
+ <file>/usr/local</file> 以下にインストールすることは
+ 絶対に無いと決まっているからです。このディレクトリ
以下は個別のシステムの管理者が使うために予約されています。
Debian システム上でパッケージからインストールされるファイルは
その代わりに <file>/usr</file> へインストールされます。
- <p>バイナリ、アイコン、文書など、それぞれのファイルを
- 保存すべき場所については、
- 「ファイルシステム体系基準」 (/usr/share/doc/debian-policy/fhs を参照)
+ <p>バイナリ、アイコン、文書など、
+ それぞれのファイルを保存すべき場所については、
+ 「ファイルシステム体系基準」 (/usr/share/doc/debian-policy/fhs を参照)
の中でより正確に規定されています。もしまだ読んだことが無ければ、
ざっと目を通して、あなたのパッケージに関係しそうな箇所をきちんと
読んでおくことをお勧めします。
@@ -661,8 +690,8 @@
定めていますから、後で gentoo のマニュアルを作成して、それを
/usr/share/man/man1 以下へインストールすることにします。
- <p>プログラムの中には、このようなパスを定義するための makefile 変数を
- 使っていないものもあります。このような場合、C のソースそのものを
+ <p>プログラムの中には、このようなパスを定義するための makefile
+ 変数を使っていないものもあります。このような場合、C のソースそのものを
いじって、指定された場所を使うように修正しなければなりません。
でもどこを、そして何を探せばよいのでしょうか？
以下のコマンドを実行すれば該当箇所を見つけることができます。
@@ -673,11 +702,11 @@
<p>これを使うと、grep がソースツリーを再帰的に検索し、
該当箇所を見つけたらそのファイルの名前と検索対象の文字列
- （ここでは usr/local/lib）を含む行とを表示します。
+ (ここでは usr/local/lib) を含む行とを表示します。
- <p>見つかったファイルを編集して usr/local/ という部分を usr/ に
- 置き換えてください。これでもう作業完了です。
- 他の部分をいじってぐちゃぐちゃにしないよう気をつけましょう。:-)
+ <p>見つかったファイルを編集して usr/local/ という部分を usr/
+ に置き換えてください。これでもう作業完了です。
+ 他の部分をいじってぐちゃぐちゃにしないよう気をつけましょう。:-)
<p>修正が終ったら、インストールターゲットを探しましょう(「install:」
で始まる行を探してください。この方法でたいていうまくいきます)。
@@ -703,11 +732,11 @@
<p>たぶんお気づきになったでしょうが、変更後はこのルールの
先頭に <tt>install -d</tt> コマンドが追加されています。
- 普通「make install」を実行するようなシステムなら /usr/local/bin や
- その他のディレクトリは既にシステム上に存在しているでしょうから、
+ 普通「make install」を実行するようなシステムなら /usr/local/bin
+ やその他のディレクトリは既にシステム上に存在しているでしょうから、
もともとの makefile ではこのコマンドは使われていませんでした。
- しかし、Debian パッケージを作成する場合には、空っぽの（あるいは
- まだ存在さえしていない）ディレクトリにインストールするわけですから、
+ しかし、Debian パッケージを作成する場合には、空っぽの(あるいは
+ まだ存在さえしていない)ディレクトリにインストールするわけですから、
これらのディレクトリのそれぞれを毎回作成する必要があります。
<p>ルールの最後には、上流作者が省略することの多い付加的な資料の
@@ -723,9 +752,9 @@
のに気づくでしょう。 こういうのをバグフィックスというのですな。:-)
<p>今のような、特に Debian パッケージだけに限定されない変更を行った場合、
- 毎回その内容を上流メンテナに報告し、プログラムの次のリビジョンに反映して
- もらうことで、他のすべての利用者にとっても有益な結果をもたらすように
- しましょう。
+ 毎回その内容を上流メンテナに報告し、
+ プログラムの次のリビジョンに反映してもらうことで、
+ 他のすべての利用者にとっても有益な結果をもたらすようにしましょう。
また、あなたの修正を送る前に、Debian や Linux (あるいは Unix でさえも!)
だけに通用するものでなく、できるだけ広範囲に通用するよう心がけることで、
上流の開発者があなたの変更を採用しやすくなるように努めましょう。
@@ -754,12 +783,17 @@
LIBS = -lncurses -lなんとか -lかんとか
</example>
+ <p>(libncurses パッケージが libcurses.so の symlink
+ を持つようになったことで
+ これが最良の例ではないことを筆者は分かっていますが、
+ よりよい案を思いつきません。。提案は大歓迎です :-)
+
<chapt id="dreq"> debian/ ディレクトリ以下に無くてはならないファイル
<p>プログラムのソースディレクトリの中に、「debian」という
名前の新しいディレクトリが作られています。
パッケージの動作を自分の意図に合わせて調整するには、
- このディレクトリに存在する多くのファイルをその編集します。
+ このディレクトリに存在する多くのファイルを編集します。
最も重要なファイルは「control」、「changelog」、「copyright」、
そして「rules」であり、これらのファイルはすべてのパッケージが
必ず用意しなければならないものです。
@@ -778,7 +812,7 @@
3 Priority: optional
4 Maintainer: Josip Rodin <joy-mg@debian.org>
5 Build-Depends: debhelper (>> 3.0.0)
- 6 Standards-Version: 3.5.2
+ 6 Standards-Version: 3.6.2
7
8 Package: gentoo
9 Architecture: any
@@ -817,40 +851,37 @@
「サーバー」を作るためのものです。ご存知ですよね。）
<p>ここでは x11 に変更しておきましょう。
- （「main」セクションは省略時のデフォルトなので、
- ここには書きません。）
+ (「main」セクションは省略時のデフォルトなので、
+ ここには書きません。)
<p>3 行目はこのパッケージをインストールすることが
ユーザにとってどれくらい重要なものかを示しています。
このフィールドに何を設定すべきかについては、
Debian ポリシーマニュアルの説明を読んでください。
- 新規パッケージの場合、優先度「optional」（選択可能）
+ 新規パッケージの場合、優先度「optional」(選択可能)
としておけば、通常は問題無いでしょう。
<p>セクション(Section) と優先度 (Priority) は、
- <prgn/dselect/ のようなフロントエンドが
- パッケージをソートする時とデフォルトを選ぶ時に
- 使われます。パッケージを Debian にアップロードすると、
- これらのフィールドの値はアーカイブメンテナたちによって
- 上書きされる場合があります。このような場合、該当する
- パッケージのメンテナにそのことを知らせるための
- 電子メールが届きます。
- （訳注：具体的な仕組みを説明すると、dpkg などのツールは
+ <prgn/dselect/ のようなフロントエンドがパッケージを
+ ソートする時とデフォルトを選ぶ時に使われます。パッケージを
+ Debian にアップロードすると、これらのフィールドの値は
+ アーカイブメンテナたちによって上書きされる場合があります。
+ このような場合、該当するパッケージのメンテナに
+ そのことを知らせるための電子メールが届きます。
+ (訳注：具体的な仕組みを説明すると、dpkg などのツールは
アーカイブ中に用意される「Packages」ファイルの情報を
- パッケージ自体に記録された情報より優先するようになって
- います。そしてこの Packages ファイルの作成と更新は
- アーカイブメンテナの（たくさんある）仕事のひとつ、
- というわけです。）
+ パッケージ自体に記録された情報より優先するようになっています。
+ そしてこの Packages ファイルの作成と更新はアーカイブメンテナの
+ (たくさんある)仕事のひとつ、というわけです。)
<p>この gentoo は通常の優先度を持つパッケージですし、
他のパッケージと衝突することもありませんから、
ここでは「optional」のままにしておきましょう。
<p>4 行目はメンテナの名前と電子メールアドレスです。
- 電子メールの宛先として問題無くそのまま使えるように
- 記載してください。Debian のバグ追跡システムは、
- パッケージがアップロードされたら、ここに記載された
- 情報を使ってあなたにユーザーからのバグ報告を
+ 電子メールの宛先として問題無くそのまま使えるように記載してください。
+ Debian のバグ追跡システムは、パッケージがアップロードされたら、
+ ここに記載された情報を使ってあなたにユーザーからのバグ報告を
転送しようとします。コンマ ,、アンド記号 &、
および括弧 () などの使用は避けてください。
@@ -867,15 +898,13 @@
ところでもうすこし詳しく説明します。
<p>ここには Build-Depends-Indep や Build-Conflicts など、
- その他のソース依存関係を設定することもできます。
- これらの情報は Debian がサポートしている他のコンピュータ
- プラットフォーム用にバイナリパッケージを作成する
- 自動パッケージ生成プログラムによって利用されます。
- ソース依存関係についての詳細は Debian ポリシーマニュアルを、
- また Debian がサポートしているプラットフォーム
- （アーキテクチャ）と、ソフトウェアをそれらへ移植
- （ポート）する方法については開発者レファレンスを
- 参照してください。
+ その他のソース依存関係を設定することもできます。これらの情報は
+ Debian がサポートしている他のコンピュータプラットフォーム用に
+ バイナリパッケージを作成する自動パッケージ生成プログラムによって
+ 利用されます。ソース依存関係についての詳細は Debian
+ ポリシーマニュアルを、また Debian がサポートしているプラットフォーム
+ (アーキテクチャ)と、ソフトウェアをそれらへ移植(ポート)
+ する方法については開発者レファレンスを参照してください。
<p>以下のようにすれば、自分のパッケージを生成するために
必要となるパッケージを見つけることができます。
@@ -891,6 +920,24 @@
echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
done
</example>
+ <p>このスクリプトは "Build-depends" のバージョン番号を全て返してきます。
+ バージョン依存については、安定版 (stable) で条件が満たされるものは
+ "Build-depends" でバージョンを特定すべきではないことに注意してください。
+
+ <p><prgn><var>/usr/bin/foo</var></prgn>
+ の実際のビルド依存を確認するには
+ <example>
+ objdump -p <var>/usr/bin/foo</var> | grep NEEDED
+ </example>
+ として表示される各ライブラリについても、例えば
+ <prgn>libfoo.so.6</prgn> の場合
+ <example>
+ dpkg -S libfoo.so.6
+ </example>
+ とします。それから `Build-deps' にある各パッケージの -dev
+ バージョンについても処理していきます。この目的で <prgn>ldd</prgn>
+ を使うとライブラリの間接的な依存も同様に示されるので、
+ 過度のビルド依存という問題を起こすことになります。
<p>Gentoo の場合、パッケージを生成するために
<package/xlibs-dev/、<package/libgtk1.2-dev/
@@ -904,14 +951,12 @@
<p>8 行目はバイナリパッケージの名前です。これは通常ソースパッケージ
の名前と同じですが、いつもそうだとは限りません。
- <p>9 行目にはバイナリパッケージをコンパイル可能な CPU アーキテクチャ
- を記述します。
- ここを「any」のままにしておけば、
+ <p>9 行目にはバイナリパッケージをコンパイル可能な CPU
+ アーキテクチャを記述します。ここを「any」のままにしておけば、
<manref name="dpkg-gencontrol" section="1">が、このパッケージを
コンパイルしたマシンに合わせて適当に埋めてくれます。
- <p>
- あなたのパッケージが特定のアーキテクチャに依存しないのであれば
+ <p>あなたのパッケージが特定のアーキテクチャに依存しないのであれば
(例えば、シェルや Perl のスクリプトであるとか、あるいは
文書のパッケージである場合) ここを「all」に変更し、パッケージの
生成に「binary-arch」ではなく「binary-indep」を使う方法について
@@ -924,15 +969,14 @@
Suggests:、Pre-depends:、Conflicts:、Provides:、Replaces: が
あります。
- <p>dpkg、dselect、APT (そしてそのフロントエンド) などの
- パッケージ管理ツールは、通常これらの関係を処理する場合に、
- 同じ動作をします。
+ <p>dpkg、dselect、APT (そしてそのフロントエンド)
+ などのパッケージ管理ツールは、
+ 通常これらの関係を処理する場合に同じ動作をします。
そうでない場合については、追々説明していきます。
(<manref name="dpkg" section="8">、
<manref name="dselect" section="8">、
<manref name="apt" section="8">、
- <manref name="aptitude" section="1">
- などを参照してください)。
+ <manref name="aptitude" section="1"> などを参照してください)。
<p>以下にこれらの依存関係が通常持つ意味を説明します。
@@ -1020,9 +1064,7 @@
「指定されたバージョン以前」(指定のバージョンも当然含まれます)、
「指定のバージョンのみ」
「指定されたバージョン以降」(指定のバージョンも当然含まれます)、
- 「指定されたものより新しいバージョンのみ」
- を意味します。
-
+ 「指定されたものより新しいバージョンのみ」を意味します。
今まで説明してきた依存関係を使うことで、例えば以下のような
指定も可能です。
@@ -1038,10 +1080,10 @@
それは $(shlibs:Depends) です。パッケージを生成する際に、
その中身が一時的なディレクトリにインストールされた後、
そこに含まれるバイナリとライブラリによって利用されている
- 共有ライブラリと、それらの共有ライブラリを含むパッケージ
- の名前 (例えば libc6 や xlib6g など) が
- <manref name="dh_shlibdeps" section="1"> によって自動的に
- 調べられます。そしてその結果は
+ 共有ライブラリと、それらの共有ライブラリを含むパッケージの名前
+ (例えば libc6 や xlib6g など) が
+ <manref name="dh_shlibdeps" section="1">
+ によって自動的に調べられます。そしてその結果は
<manref name="dh_gencontrol" section="1"> に渡され、control
ファイル中の $(shlibs:Depends) と置換されます。
これを使えば、あなた自身が自分で共有ライブラリを調べて記述する
@@ -1056,7 +1098,7 @@
<p>11 行目はこのパッケージに関する短い説明です。多くの人々は
一行 (半角) 80 文字幅のスクリーンでこれを見ますから、
(半角) 60 文字以上にしてはいけません。
- 今回は「fully GUI configurable X file manager using GTK+」
+ 今回は「A fully GUI configurable X file manager using GTK+」
としました。
<p>12 行目はこのパッケージに関する詳細な説明文です。
@@ -1081,7 +1123,7 @@
9 Architecture: any
10 Depends: ${shlibs:Depends}
11 Suggests: file
- 12 Description: fully GUI configurable GTK+ file manager
+ 12 Description: A fully GUI configurable GTK+ file manager
13 gentoo is a file manager for Linux written from scratch in pure C. It
14 uses the GTK+ toolkit for all of its interface needs. gentoo provides
15 100% GUI configurability; no need to edit config files by hand and re-
@@ -1099,7 +1141,7 @@
<p>このファイルにはパッケージの上流 (upstream) に関する
リソース (URI など)、著作権、およびライセンスなどの情報を記載します。
このファイルの書式は Debian ポリシーに規定されていませんが、
- 内容については (12.6 節、「Copyright information (著作権情報)」に)
+ 内容については (13.6 節、「Copyright information (著作権情報)」に)
規定されています。
<p>dh_make はデフォルトとして以下のようなひな型を作成します。
@@ -1142,12 +1184,16 @@
9 Development.
10
11 You are free to distribute this software under the terms of
- 12 the GNU General Public License.
- 13 On Debian systems, the complete text of the GNU General Public
- 14 License can be found in the file `/usr/share/common-licenses/GPL'.
+ 12 the GNU General Public License either version 2 of the License,
+ 13 or (at your option) any later version.
+ 14 On Debian systems, the complete text of the GNU General Public
+ 15 License can be found in the file `/usr/share/common-licenses/GPL-2'.
</example>
(行番号は筆者が書き加えました)
+ <p>debian-devel-announce <url id="©right-howto;">
+ に投稿された手順を追ってみてください。
+
<sect id="changelog">「changelog」ファイル
<p>これは必須のファイルです。ポリシーマニュアル 4.4 節
@@ -1193,10 +1239,8 @@
/usr/share/doc/gentoo/changelog.gz としてインストールされる
専用のファイルが存在しています)。
新しい行はアスタリスク(「*」)で始まる最初の行の直前に挿入します。
- この操作は
- <manref name="dch" section="1"> を使うと便利ですが、
- その他の普通のテキストエディタを使って実行しても
- もちろん構いません。
+ この操作は <manref name="dch" section="1"> を使うと便利ですが、
+ その他の普通のテキストエディタを使って実行してももちろん構いません。
<p>最終的にこんな風になればよいわけです。
@@ -1219,9 +1263,8 @@
<p>さて、今度は <manref name="dpkg-buildpackage" section="1"> が
実際にパッケージを作成するために使う「rules」ファイルを
- 調べる必要があります。
- このファイルは実はもう一つの Makefile といったものですが、
- 上流ソースに含まれる Makefile とは違います。
+ 調べる必要があります。このファイルは実はもう一つの Makefile
+ といったものですが、上流ソースに含まれる Makefile とは違います。
また debian/ ディレクトリに含まれる他のファイルとは異なり、
このファイルには実行属性が付けられています。
@@ -1229,8 +1272,7 @@
ソースからプログラムを構築する方法を記述したいくつかの
ルールによって構成されています。それぞれのルールには
ターゲット、ファイル名、あるいは実行されるべき動作
- (つまり「build:」や「install:」) などの名前がつけられて
- います。
+ (つまり「build:」や「install:」) などの名前がつけられています。
あるルールを実行するには (例えば「./debian/rules build」
とか「make -f rules install」といった風に) そのルールを
コマンドライン引数として指定します。
@@ -1249,9 +1291,9 @@
また、info コマンドの「make」エントリーに、より詳細な説明が
あるので、これも合わせて読んでおくと良いでしょう。
- <p>dh_make によって作成された rules ファイルについて知っておくべき
- 最も重要なことは、これが単なるひな型であり、ひとつの例でしかない、
- ということです。
+ <p>dh_make によって作成された rules
+ ファイルについて知っておくべき最も重要なことは、
+ これが単なるひな型であり、ひとつの例でしかない、ということです。
単純なパッケージならそのまま使えるかもしれませんが、
もっと複雑なパッケージの場合には、必要に応じて追加したり
削除したりすることをためらってはいけません。
@@ -1318,9 +1360,11 @@
<p>18 行目から 26 行目までは「build」 (およびその子供である
「build-stamp」) ルールを記述しており、その中でプログラムを
コンパイルするためにアプリケーション自身の Makefile を実行
- しています。コメントとして記載されている docbook-to-man の
- サンプルについては、後で説明する <ref id="manpage"> の箇所を
- 参照してください。
+ しています。バイナリパッケージの作成に GNU configure
+ ユーティリティを使用している場合は <file>&autotools-dev;</file>
+ を確実に熟読してください。コメントとして記載されている
+ docbook-to-man のサンプルについては、後で説明する
+ <ref id="manpage"> の箇所を参照してください。
<p>28 行目から 36 行目までに記述されている「clean」ルールは、
パッケージの生成過程によって自動生成されたバイナリその他の
@@ -1392,7 +1436,7 @@
<p>これらすべての dh_* スクリプトが実際にはそれぞれ何をするのか、
また他にはどんなオプションが使えるのか、などのさらに詳しい情報に
ついては、それぞれのマニュアルページを参照してください。
- また、ここでは取り上げませんでしたが、非常に便利だと思われる
+ また、ここでは取り上げませんでしたが、(非常に便利だと思われる)
dh_* スクリプトが他にもいくつか用意されています。
これらに関しては、必要に応じて debhelper の説明書を読んでみて
ください。
@@ -1498,8 +1542,7 @@
<p>ここではログのローテーションは扱いません。
ログローテーションについては
<manref name="dh_installlogrotate" section="1"> および
- <manref name="logrotate" section="8">
- を参照してください。
+ <manref name="logrotate" section="8"> を参照してください。
<p>もし必要無ければ、このファイルを削除してください。
@@ -1562,9 +1605,8 @@
<p>ありそうにないことですが、パッケージのソース中にここで
指定したくなるような附属文書がまったく存在しないという
- 場合もあるかもしれません。
- そうした場合には、この docs ファイルを削除しても問題無い
- でしょう。
+ 場合もあるかもしれません。そうした場合には、この docs
+ ファイルを削除しても問題無いでしょう。
ただし、その場合にも <tt/rules/ ファイルの中の
<tt/dh_installdocs/ コマンドを削除してはいけません。
このコマンドは <tt/copyright/ ファイルやその他のファイルを
@@ -1612,31 +1654,18 @@
もし無かったら、これらのひな型のどちらかを利用して、
必要な情報を追加すれば作成できます。
- <p>マニュアルページは通常
- <manref name="nroff" section="1">
- を利用して作成されます。
- これにならって、<tt/manpage.1.ex/ も nroff で
- 作成されています。
+ <taglist>
+
+ <tag><file/manpage.1.ex/
+ <item><p>マニュアルページは通常 <manref name="nroff" section="1">
+ を利用して作成されます。これにならって、<tt/manpage.1.ex/ も
+ nroff で作成されています。
<manref name="man" section="7"> のマニュアルページには、
このファイルの編集方法についての簡潔な説明があります。
- <p>一方、もし nroff より SGML のほうが好みでしたら、
- <tt/manpage.sgml.ex/ のほうをひな型として使うことも
- できます。こちらの場合には、以下の手順が必要です。
- <list>
- <item>パッケージ <package/docbook-to-man/ のインストール
- <item><tt/control/ ファイルの <tt/Build-Depends/ 行へ
- <tt/docbook-to-man/ を追加
- <item><tt/rules/ ファイルに記述された「build」ルールの
- 中で docbook-to-man を実行している行を有効にする
- </list>
-
- <p>それから、このファイルの名前を <tt/gentoo.sgml/ と
- いった名前に変更することを忘れないように!
-
<p>最終的なマニュアルページファイルの名前には、そのマニュアル
ページで解説するプログラムの名前が含まれているべきです。
- このため、ここではファイル名を「gentoo」から「manpage」に
+ このため、ここではファイル名を「manpage」から「gentoo」に
変更します。ファイル名にはまた、デフォルトの拡張子として
「.1」が含まれていますが、これはこのファイルがユーザー
コマンドのマニュアルページであることを示しています。
@@ -1663,6 +1692,65 @@
上に説明したサンプルと、上流開発者が提供している文書からの情報を
もとに筆者が作成しました。
+
+ <tag><file/manpage.sgml.ex/
+ <item><p>一方、もし nroff より SGML のほうが好みでしたら、
+ <tt/manpage.sgml.ex/ のほうをひな型として使うことも
+ できます。こちらの場合には、以下の手順が必要です。
+
+ <list>
+ <item>パッケージ <package/docbook-to-man/ のインストール
+ <item><tt/control/ ファイルの <tt/Build-Depends/ 行へ
+ <tt/docbook-to-man/ を追加
+ <item><tt/rules/ ファイルに記述された「build」ルールの
+ 中で docbook-to-man を実行している行を有効にする
+ </list>
+
+ <p>それから、このファイルの名前を <tt/gentoo.sgml/ と
+ いった名前に変更することを忘れないように!
+
+ <tag><file/manpage.xml.ex/
+ <item><p>SGML よりも XML が良かったら、<tt/manpage.xml.ex/
+ テンプレートを使うことも可能です。
+ その場合、選択肢が 2 つあります。
+
+ <list>
+ <item><package/docbook-xsl/ パッケージと
+ <package/xsltproc/ (推奨) のような XSLT プロセッサのインストール
+ <item><tt/control/ ファイルの <tt/Build-Depends/ 行に
+ <tt/docbook-xsl/, <tt/docbook-xml/ 及び <tt/xsltproc/
+ パッケージを追加
+ <item><tt/rules/ ファイルの `build' ターゲットにルールを追加
+ <example>
+xsltproc --nonet \
+ --param make.year.ranges 1 \
+ --param make.single.year.ranges 1 \
+ --param man.charmap.use.subset 0 \
+ -o debian/ \
+ /usr/share/xml/docbook/stylesheet/nwalsh/manpages/docbook.xsl \
+ debian/manpage.xml
+ </example>
+ </item>
+ </list>
+
+ <p>別の方法
+
+ <list>
+ <item><package/docbook2x/ パッケージをインストール
+ <item><tt/control/ ファイルの <tt/Build-Depends/ 行に
+ <tt/docbook2x/ パッケージを追加
+ <item><tt/rules/ ファイルの `build' ターゲットにルールを追加
+ <example>
+docbook2man debian/manpage.xml
+ </example>
+ </item>
+ </list>
+
+ <p>ソースファイルを <tt/gentoo.1.xml/ の様に変更して
+ スタイルシートのパラメータや出力オプションに関するパッケージ文書を確認
+
+ </taglist>
+
<sect id="menu">menu.ex
<p>X Window System のユーザはたいていウィンドウマネージャを
@@ -1676,7 +1764,7 @@
ファイルです。
<p><example>
- ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\
+ ?package(gentoo):needs="X11|text|vc|wm" section="Apps/see-menu-manual"\
title="gentoo" command="/usr/bin/gentoo"
</example>
@@ -1700,7 +1788,7 @@
<p>さて、今回はこんな風に menu エントリを変えましょう。
<p><example>
- ?package(gentoo): needs=X11 section=Apps/Tools title="Gentoo" command="gentoo"
+ ?package(gentoo): needs="X11" section="Apps/Tools" title="Gentoo" command="gentoo"
</example>
<p>他にも「longtitle」、「icon」、「hints」などの
@@ -1708,8 +1796,8 @@
より詳細な説明は
<manref name="menufile" section="5">、
<manref name="update-menus" section="1">、
- および <file>/usr/share/doc/debian-policy/menu-policy.html/</file> を
- 参照してください。
+ および <file>/usr/share/doc/debian-policy/menu-policy.html/</file>
+ を参照してください。
<sect id="watch">watch.ex
@@ -1766,6 +1854,9 @@
<file>/usr/share/doc/doc-base/doc-base.html/</file> にある
<package/doc-base/ のマニュアルを参照してください。
+ <p>追加文書のインストールに関する詳細については、
+ <ref id="destdir"> を読んでみてください。
+
<sect id="maintscripts">postinst.ex、preinst.ex、postrm.ex、prerm.ex
<p>これらのファイルはメンテナスクリプトと呼ばれるもので、
@@ -1776,8 +1867,7 @@
<p>今のところは、メンテナスクリプトを手でいじるのは、
できるだけ避けるようにするべきでしょう。
というのも、これらはどんどん複雑になっていってしまう傾向が
- あるからです。
- 詳しくはポリシーマニュアルの第 6 章と
+ あるからです。詳しくはポリシーマニュアルの第 6 章と
dh_make によって用意されたこれらのサンプルファイルを
注意して読んでください。
@@ -1794,9 +1884,8 @@
dpkg-buildpackage -rfakeroot
</example>
- <p>このコマンドは、あなたのためにパッケージ構築の
- 作業をすべて行なってくれます。これには以下の作業が
- 含まれます。
+ <p>このコマンドはパッケージ構築の作業をすべて行なってくれます。
+ これには以下の作業が含まれます。
<list>
<item><prgn/fakeroot/ を使ったソースツリーの初期化 (debian/rules clean)
@@ -1811,7 +1900,7 @@
<p>途中で GPG の秘密鍵を 2 回入力する必要がありますが、
それを除けばこのプログラムにすべてお任せで大丈夫です。
- <p>一連の作業が終わった後、上記のディレクトリ (<tt>~/debian/</tt>) には
+ <p>一連の作業が終わった後、上記のディレクトリ (<file>~/gentoo/</file>) には
以下のファイルが作成されているはずです。
<p><list>
@@ -1832,6 +1921,7 @@
作成したものかどうかを利用者が検証できます。
<item><em>gentoo_0.9.12-1.diff.gz</em>
+
<p>この圧縮されたファイルにはあなたがオリジナルのソースコードに
行なったすべての変更や追加などの情報が「unified diff」の形式で
含まれています。これは <manref name="dpkg-source" section="1">
@@ -1894,8 +1984,96 @@
このやり方で生成した .deb ファイルをアップロードしようと
しても、おそらくきちんとアップロードできないでしょう。
+ <sect id="debuild"><prgn>debuild</prgn> コマンド
+
+ <p><prgn>debuild</prgn> コマンドによって、
+ ビルドプロセスの更なる自動化が図れます。
+ <manref name="debuild" section="1"> を読んでください。
+
+ <p><file>/etc/devscripts.conf</file> や <file>~/.devscripts</file>
+ によって、debuild コマンドのカスタマイズが行えます。
+ 最低限のものとして、以下の項目を提案します。
+
+ <p><example>
+ DEBSIGN_KEYID="Your_GPG_keyID"
+ DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn"
+ </example>
+ これによって、常に自分の GPG 鍵で署名したパッケージを
+ ビルドすることができ、またバージョン管理システム (VCS)
+ の管理ファイル群を意図せず含めてしまうのを防げます。
+ (これはスポンサーの作業にも適しています。)
+ 例えば、一般ユーザアカウントから、
+ ソースを除去してパッケージを再ビルドするのは
+ このようにとても単純です。
+
+ <p><example>
+ debuild clean
+ debuild
+ </example>
+
+ <sect id="dpatch"><prgn>dpatch</prgn> 及び <prgn>quilt</prgn> システム
+ <p><prgn>dh_make</prgn> 及び <prgn>dpkg-buildpackage</prgn>
+ コマンドの単純な使い方では、<file>debian/</file>
+ にあるパッケージ保守ファイルやソースに対するパッチファイルを内包した、
+ 単一の巨大な <file>diff.gz</file> が作成されます。
+ こうしたパッケージは後で各ソースツリーを変更するに当たって、
+ 調べたり理解するのに少々厄介です。あまりよいことではないですね。
+<footnote>
+ まだ Debian 開発者になっていなくて、
+ スポンサーにレビューとその後のアップロードを依頼する場合、
+ できるだけレビューしやすいパッケージを作成すべきです。
+</footnote>
+ <p>パッチセットの保守方法は何種類か提案され、Debian
+ パッケージで使用されています。<prgn>dpatch</prgn> 及び
+ <prgn>quilt</prgn> システムはそうして提案されたパッチ保守システムで
+ もっとも単純な 2 つです。他には dbs や cdbs 等があります。
+
+ <p><prgn>dpatch</prgn> や <prgn>quilt</prgn>
+ システムで適切に作られたパッケージは、変更点が
+ <file>debian/patches/</file> にある -p1 形式のパッチファイルとヘッダ
+ の形で明確にされ、<file>debian/</file>
+ ディレクトリにあるものを除いてソースツリーを変更しません。
+ パッケージのアップロードをスポンサーに依頼する場合、
+ こうして変更点を明確に分離して資料を用意することは、
+ スポンサーがパッケージのレビューを円滑に進める上で非常に重要になってきます。
+ <prgn>dpatch</prgn> 及び <prgn>quilt</prgn> の使用手順については、
+ <manref section="1" name="dpatch">,
+ <manref section="1" name="dpatch-edit-patch"> 及び
+ <manref section="1" name="quilt"> で説明されています。
+ どちらのプログラムも <file>debian/rules</file>
+ で読み込む便利なファイル、それぞれ
+ <file>/usr/share/dpatch/dpatch.make</file> と
+ <file>/usr/share/quilt/quilt.make</file> を提供します。
+
+ <p>(あなたを含めた)誰かが後でパッチを提供してくれた場合、
+ パッケージの変更は相当単純になります。
+<list compact>
+ <item>パッチをソースツリーへの -p1 形式に編集
+ <item><prgn>dpatch</prgn> の場合は `<tt>dpatch patch-template</tt>'
+ コマンドを使ってヘッダを追加
+ <item><file>debian/patches</file> に持って行く
+ <item><file>debian/patches/00list</file> (<prgn>dpatch</prgn> 用)
+ や <file>debian/patches/series</file> (<prgn>quilt</prgn> 用)
+ にパッチのファイル名を追加
+</list>
+ <p>また、<prgn>dpatch</prgn> には CPP マクロを使用することで、
+ それに従った構造でパッチを作る機能があります。
+
+ <sect id="option-sa">アップロードするため
+ <file>orig.tar.gz</file> を含める
+
+ <p>パッケージを最初にアーカイブにアップロードする際、
+ もとの <file>orig.tar.gz</file> ソースを含める必要があります。
+ パッケージのバージョンが Debian のリビジョンで <tt>-0</tt> か
+ <tt>-1</tt> にならない場合、<prgn>dpkg-buildpackage</prgn>
+ コマンドに "<tt>-sa</tt>" オプションを付けてそれを提供しなければなりません。
+ 逆に、"<tt>-sd</tt>" オプションを付けると元の <file>orig.tar.gz</file>
+ ソースを除外します。
+
<chapt id="checkit">できたパッケージの誤りを調べる
+ <sect id="lintians"><package>lintian</package> パッケージ
+
<p><manref name="lintian" section="1"> をあなたの .changes ファイルに
かけてみましょう。このプログラムはパッケージ化におけるよくある間違いを
チェックしてくれます。実行するコマンドは以下のとおりです。
@@ -1918,30 +2096,132 @@
<prgn/lintian/ の実行をすべてひとつのコマンド
<manref name="debuild" section="1"> で行なうこともできます。
- <p><manref name="mc" section="1"> などのファイルマネージャを
- 使ってパッケージの中を見たり、<manref name="dpkg-deb" section="1">
- を使ってパッケージの中身を一時的な場所へ取り出したりしてみましょう。
- なにかがうまく行かず、妙なものが削除されないまま残されてしまった
+ <sect id="mc"><prgn>mc</prgn> コマンド
+
+ <p><file>*.deb</file> パッケージは <manref name="dpkg-deb" section="1">
+ コマンドにより展開することが出来ます。生成された Debian
+ パッケージの内容は <manref name="debc" section="1">
+ で一覧することができます。
+
+ <p><file>*.deb</file> パッケージ以外にも <file>*.diff.gz</file> や
+ <file>*.tar.gz</file> ファイルの内容も見られる
+ <manref name="mc" section="1"> 等のファイルマネージャにより、
+ これについては直感的に行うことが可能です。
+
+ <p>なにかがうまく行かず、妙なものが削除されないまま残されてしまった
場合に備えて、バイナリおよびソースパッケージの両方について不要な
ファイルが余分に含まれたりしていないかどうか、しっかり検査して
ください。
- ヒント:「zgrep ^+++ ../gentoo_0.9.12-1.diff.gz」を実行すると、
+
+ <p>ヒント:「<tt>zgrep ^+++ ../gentoo_0.9.12-1.diff.gz</tt>」を実行すると、
ソースファイルに対してあなたが行なった変更や追加のリストを
得ることができます。
- また `dpkg-deb -c gentoo_0.9.12-1_i386.deb` を実行すると
+ また `<tt>dpkg-deb -c gentoo_0.9.12-1_i386.deb</tt>` や
+ `<tt>debc gentoo_0.9.12-1_i386.changes</tt>' を実行すると
バイナリパッケージ中のファイルのリストを得ることができます。
+ <sect id="debdiff"><prgn>debdiff</prgn> コマンド
+
+ <p><manref name="debdiff" section="1"> コマンドで 2 つのバイナリ
+ Debian パッケージのファイル一覧を比較することができます。
+ 意図せず誤った位置に配置したり削除してしまったファイルがないか、
+ パッケージの更新にあたって他に不注意で変更したところがないか、
+ ということを確認するのに便利です。<file>*.deb</file>
+ ファイルのグループを単純に `<tt>debdiff
+ old-package.change new-package.change</tt>'
+ とすることでチェックできます。
+
+ <sect id="interdiff"><prgn>interdiff</prgn> コマンド
+
+ <p><manref name="interdiff" section="1"> コマンドで 2 つの
+ <file>diff.gz</file> ファイルを比較することができます。
+ パッケージの更新にあたってソースが不注意で変更されていないか、
+ メンテナが確認するのに便利です。
+ `<tt>interdiff -z old-package.diff.gz new-package.diff.gz</tt>'
+ とします。
+
+ <sect id="debi"><prgn>debi</prgn> コマンド
+
<p>自分でパッケージをインストールして試してみましょう。
例えば、<manref name="debi" section="1"> コマンドを root で
実行してみましょう。
自分の環境以外のマシンでも試してみて、パッケージをインストール
する際やプログラムを実行する際に警告やエラーが発生しないか
注意深く観察してみてください。
-
+
+ <sect id="pbuilder"><package>pbuilder</package> パッケージ
+
+ <p>ビルド依存を確認するための無菌室 (chroot) なビルド環境では
+ <package>pbuilder</package> パッケージが非常に便利です。
+ これによって、異なるアーキテクチャ向けのオートビルダーの下での
+ ソースからのクリーンビルドが保証され、極めて深刻な FTBFS
+ (Fails To Build From Source) バグを防いでくれます。
+ FTBFS バグは常に RC (release critical) に分類されます。
+ Debian パッケージのオートビルダーについてもっと知りたい場合は
+ <url id="&buildd-home;"> を見てください。
+
+ <p><package>pbuilder</package> パッケージの最も基本的な使い方は
+ root で <prgn>pbuilder</prgn> コマンドを直接実行することです。
+ 例えば <file>.orig.tar.gz</file>, <file>.diff.gz</file>,
+ そして <file>.dsc</file> ファイルがあるディレクトリから
+ 以下のコマンドを実行してパッケージをビルドします。
+<example>
+root # pbuilder create # 2 回目なら pbuilder update
+root # pbuilder build foo.dsc
+</example>
+ 新しくビルドされたパッケージは root 所有で
+ <file>/var/cache/pbuilder/result/</file> に置かれます。
+
+ <p><prgn>pdebuild</prgn> コマンドによって
+ ノーマルユーザアカウントからの <package>pbuilder</package>
+ パッケージの使用を補助します。
+ <file>orig.tar.gz</file> ファイルがその親ディレクトリにある状態で
+ ソースツリーのルートから以下のコマンドを実行します。
+<example>
+$ sudo pbuilder create # 2 回目なら sudo pbuilder update
+$ pdebuild
+</example>
+ 新しくビルドされたパッケージは非 root 所有で
+ <file>/var/cache/pbuilder/result/</file> に置かれます。
+<footnote>
+ 現時点では、<file>/var/cache/pbuilder/result/</file>
+ ディレクトリをユーザから書き込み可能にし、
+ <file>~/.pbuilderrc</file> や <file>/etc/pbuilderrc</file> に
+<example>
+AUTO_DEBSIGN=yes
+</example>
+ を含める様にシステムを設定することを提案します。これによって、
+ <file>~/.gnupg/</file> にある GPG
+ 秘密鍵による署名がされたパッケージを作成することが可能になります。
+ <package>pbuilder</package> パッケージは進化しているので、
+ 最新の公式文書をあたって実際の設定状況を確認しなければなりません。
+</footnote>
+ <p><package>pbuilder</package> パッケージで apt
+ ソースを追加で使いたい場合、<file>~/.pbuilderrc</file> または
+ <file>/etc/pbuilderrc</file> で <tt>OTHERMIRROR</tt>
+ をセットして
+<example>
+$ sudo pbuilder update --distribution sarge --override-config
+</example>
+ を実行します (sarge の場合)。
+ chroot 環境下で apt ソースをアップデートする場合、
+ <tt>--override-config</tt> の使用が必要となります。
+
+ <p><url id="&pbuilder-home;">, <manref section="1" name="pdebuild">,
+ <manref section="5" name="pbuilderrc">, 及び
+ <manref section="8" name="pbuilder"> を見てみてください。
+
<chapt id="upload">パッケージをアップロードする
- <p>徹底的に新パッケージをテストしたら、これらのファイルを
- Debian アーカイブにアップロードする必要があります。
+ <p>徹底的に新パッケージをテストしたら、
+ <url id="http://www.debian.org/devel/join/newmaint";>
+ で説明しているとおり、Debian
+ 新規メンテナプロセスを開始する準備が整ったということになります。
+
+ <sect id="upload-debian">Debian アーカイブへのアップロード
+
+ <p>公式の開発者になると、パッケージを Debian
+ アーカイブにアップロードする必要があります。
これは手作業で行なってもかまいませんが、
<manref name="dupload" section="1"> や
<manref name="dput" section="1"> のような、あらかじめ
@@ -1959,28 +2239,29 @@
<p><example>
package config;
- $default_host = "ftp-master";
-
- $cfg{"ftp-master"}{"login"} = "yourdebianusername";
+ $default_host = "anonymous-ftp-master";
- $cfg{"non-us"}{"login"} = "yourdebianusername";
+ $cfg{'anonymous-ftp-master'} = {
+ fqdn => "ftp-master.debian.org",
+ method => "ftp",
+ incoming => "/pub/UploadQueue/",
+ # files pass on to dinstall on ftp-master which sends emails itself
+ dinstall_runs => 1,
1;
</example>
- <p>もちろん、私の個人的な設定の部分はあなたの設定に従って
- 変更してください。またそれぞれのオプションが持つ意味を理解する
- ために <manref name="dupload.conf" section="5"> マニュアルページ
+ <p>それぞれのオプションが持つ意味を理解するために
+ <manref name="dupload.conf" section="5"> マニュアルページ
を読んでください。
<p>もっとも気をつけるべき項目は $default_host の選択です。
この項目にはデフォルトとして利用するアップロードキューを指定します。
- 「ftp-master」がメインのサーバーですが、場合によっては別の、もっと
+ 「anonymous-ftp-master」がメインのサーバーですが、場合によっては別の、もっと
速い (ネットワーク的に近い) ホストを利用したいこともあるでしょう。
アップロードキューについて、詳しくは開発者レファレンスの
「Uploading a package (パッケージのアップロード)」の節、
- <file>/usr/share/doc/developers-reference/developers-reference.html/ch-upload.en.html#s-uploading</file>
- を参照してください。
+ <file>&uploading;</file> を参照してください。
<p>さてそれでは、インターネットプロバイダに接続し、
以下のコマンドを実行してください:
@@ -1990,14 +2271,81 @@
</example>
<p><prgn/dupload/ は各ファイルの MD5 チェックサムを計算し、
- .changes ファイルの中の情報と照合します。
- もし一致しない場合にはうまく upload できないため、
- <ref id="completebuild"> の説明に従って最初から再構築を
- やり直すよう、警告してきます。
-
+ .changes ファイルの中の情報と照合します。もし一致しない場合には
+ <ref id="completebuild"> の説明に従って最初から再構築をやり直すよう、
+ 警告するのでうまく upload できるようになります。
+
+ <!-- (No more use of ftp-master)
<p>「ftp-master」へアップロードするよう指定した場合、
<prgn/dupload/ は Debian マシン上でのあなたのパスワードを
確認し、そしてパッケージを upload します。
+ -->
+
+ <p><url id="&ftp-uploadqueue;">
+ のアップロードに際しての問題が発生した場合は、gnupg で署名した
+ <file>*.commands</file> ファイルを <prgn>ftp</prgn> で
+ <url id="&ftp-uploadqueue;"> にアップロードすることで直せます。
+ <footnote>
+ <url id="&ftp-command;"> を見てください。別の方法として、
+ <package>dput</package> の <prgn>dcut</prgn>
+ コマンドを使うこともできます。
+ </footnote>
+ 例えば <file>hello.commands</file> を使ってこうします。
+<example>
+-----BEGIN PGP SIGNED MESSAGE-----
+
+Uploader: Roman Hodek <Roman.Hodek@xxxxxxxxxxxxxxxxxxxxxxxxxx>
+Commands:
+ rm hello_1.0-1_i386.deb
+ mv hello_1.0-1.dsx hello_1.0-1.dsc
+
+-----BEGIN PGP SIGNATURE-----
+Version: 2.6.3ia
+
+iQCVAwUBNFiQSXVhJ0HiWnvJAQG58AP+IDJVeSWmDvzMUphScg1EK0mvChgnuD7h
+BRiVQubXkB2DphLJW5UUSRnjw1iuFcYwH/lFpNpl7XP95LkLX3iFza9qItw4k2/q
+tvylZkmIA9jxCyv/YB6zZCbHmbvUnL473eLRoxlnYZd3JFaCZMJ86B0Ph4GFNPAf
+Z4jxNrgh7Bc=
+=pH94
+-----END PGP SIGNATURE-----
+</example>
+
+ <sect id="upload-private">私的なアーカイブへのアップロード
+
+ <p>開発者として単純に <tt>dupload -t <var>ターゲット名</var></tt> として
+ <tt>URL="http://people.debian.org/~<var>アカウント名</var>"</tt>
+ に私有のパッケージアーカイブを作りたい場合、
+ <file>/etc/dupload.conf</file> ファイルに以下を追加します。
+<example>
+# 開発者アカウント
+$cfg{'<var>ターゲット名</var>'} = {
+ fqdn => "people.debian.org",
+ method => "scpb",
+ incoming => "/home/<var>アカウント名</var>/public_html/package/",
+ # アナウンスは不要
+ dinstall_runs => 1,
+};
+$cfg{'<var>ターゲット名</var>'}{preupload}{'changes'} = "
+ echo 'mkdir -p public_html/package' | ssh people.debian.org 2>/dev/null ;
+ echo 'Package directory created!'";
+
+$cfg{'<var>ターゲット名</var>'}{postupload}{'changes'} = "
+ echo 'cd public_html/package ;
+ dpkg-scanpackages . /dev/null >Packages || true ;
+ dpkg-scansources . /dev/null >Sources || true ;
+ gzip -c Packages >Packages.gz ;
+ gzip -c Sources >Sources.gz ' | ssh people.debian.org 2>/dev/null ;
+ echo 'Package archive created!'";
+
+</example>
+ これで、SSH を使った簡略なリモートシェルにより APT
+ アーカイブが構成されます。<prgn>dpkg-scanpackages</prgn>
+ と <prgn>dpkg-scansources</prgn> で必要となる上書きファイルは
+ <file>/dev/null</file> としています。このやり方は Debian
+ 開発者でなくとも、
+ 私有のウェブサイトで自分のパッケージをホストするのにも使えます。
+ <prgn>apt-ftparchive</prgn> や他のスクリプトを使って
+ APT アーカイブを作ることも可能です。
<chapt id="update">パッケージの更新
@@ -2012,12 +2360,12 @@
<item>もちろん、パッケージソース中の問題を修正します。
<item>次に Debian changelog ファイルの先頭に新しいレビジョンを
- 追加します。例えば「dch -i」を実行するか、またはバージョンを
- 明示したい場合なら「dch -v <version>-<revision>」
+ 追加します。例えば「<tt>dch -i</tt>」を実行するか、またはバージョンを
+ 明示したい場合なら「<tt>dch -v <version>-<revision></tt>」
を実行してあなたの好きなエディタで説明を記入すると楽にできます。
<p>ヒント: 指定された形式で日付情報を取得する方法は ?
- 答: 「822-date」または「date -R」を使いましょう。
+ 答: 「<tt>822-date</tt>」や「<tt>date -R</tt>」を使いましょう。
<item>changelog の説明行に、このレビジョンで解決されたバグと、
@@ -2031,10 +2379,10 @@
<ref id="upload"> の中で実行してきたことを再度繰り返します。
今までと違うのは、今回の場合オリジナルソースアーカイブには
変更が無く、同じものが既に Debian アーカイブ中に存在しているため、
- upload するファイルにはこのファイルが含まれないという点だけです。
+ アップロードするファイルにはこのファイルが含まれないという点だけです。
</list>
- <sect id="newupstream">上流ソフトウェアの更新 (New upstream release)
+ <sect id="newupstream">上流ソフトウェアの更新 (基本)
<p>さて、ではまた別の、もうすこし複雑な状況を考えてみましょう。
新しい上流のバージョン (new upstream version) がリリースされ、
@@ -2042,9 +2390,9 @@
この場合、以下を実行する必要があります。
<list>
- <item>新しいソースをダウンロードして (例えば「gentoo-0.9.13.tar.gz」
+ <item>新しいソースをダウンロードして (例えば「<file>gentoo-0.9.13.tar.gz</file>」
という名前で) tarball にまとめ、古いソースツリーの上のディレクトリ
- (例えば ~/debian/) にそれを置きます。
+ (例えば <file>~/gentoo/</file>) にそれを置きます。
<item>古いソースディレクトリに移動し、以下を実行:
@@ -2054,37 +2402,232 @@
もちろん、このファイル名はあなたのプログラムのソースアーカイブ名で
置き換えてください。<manref name="uupdate" section="1"> は tarball
- の名前を適切に変更し、以前の .diff.gz ファイルにある変更をすべて
- 適用して新しい debian/changelog ファイルの内容を更新します。
+ の名前を適切に変更し、以前の <file>.diff.gz</file> ファイルにある変更をすべて
+ 適用して新しい <file>debian/changelog</file> ファイルの内容を更新します。
<item>ディレクトリを新しいパッケージソースツリーである
- 「../gentoo-0.9.13」に変更し、今まで <ref id="completebuild">、
+ 「<file>../gentoo-0.9.13</file>」に変更し、今まで <ref id="completebuild">、
<ref id="checkit">、<ref id="upload"> の中で
実行してきたことを再度繰り返します。
</list>
- <p>もし「debian/watch」ファイルを <ref id="watch"> で
+ <p>もし「<file>debian/watch</file>」ファイルを <ref id="watch"> で
説明したように設定していれば、
<manref name="uscan" section="1">
を実行して、改訂されたソースを探し、ダウンロードし、
<prgn/uupdate/ を実行、という一連の手順を (魔法のように)
自動的に行なわせることができます。
- <sect id="upgrading">Verifying package upgrades
+ <sect id="newupstream-real">上流ソフトウェアの更新 (現実的)
+
+ <p>Debian アーカイブのパッケージを作成する場合、
+ 出来上がったパッケージを細かくチェックしなければなりません。
+ この手順のもっと現実的な例を見ていきます。
+
+<enumlist compact>
+
+<item>上流ソースの変更を検証
+
+<list compact>
+
+<item>上流の <file>changelog</file>, <file>NEWS</file>, それ以外にも
+ 新しいバージョンのリリースに付いてきた文書があれば読んでみましょう。
+
+<item>新旧の上流ソースに対して `<tt>diff -urN</tt>'
+ してみて変更点を眺めてどういった変更なのか、
+ どの辺りに対する作業が多いのか
+ (作業が多いということは新しいバグが生まれやすいということになります)、
+ 何か変なところがないか注意しながらその傾向を見てみましょう。
+
+</list>
+
+<item>Debian パッケージの新しいバージョンへの移植
+
+<list compact>
+
+<item>ソース tarball を展開してソースツリーのルートを
+ <file><パッケージ名>-<上流バージョン>/</file>
+ とリネームし、そのディレクトリに `<tt>cd</tt>' します。
+
+<item>親ディレクトリのソース tarball をコピーして
+ <file><パッケージ名>_<上流バージョン>.orig.tar.gz</file>
+ とリネームします。
+
+<item>古いソースツリーと同じ変更を新しいソースツリーに適用します。
+ こんな方法が考えられます。
+<list compact>
+<item>`<tt>zcat <var>/path/to/</var><パッケージ名>_<古いバージョン>.diff.gz | patch -p1</tt>' コマンド,
+<item>`<prgn>uupdate</prgn>' コマンド,
+<item>Subversion リポジトリでソースを管理しているなら `<tt>svn merge</tt>'
+ コマンド,
+<item><package>dpatch</package> か <package>quilt</package>
+ でパッケージ化されたものであれば単純に古いソースツリーから
+ <file>debian/</file> ディレクトリをコピーするだけです
+</list>
+
+<item>changelog のエントリは維持します
+ (分かり切ったことの様に見えるでしょうが事故は起こるのです。。。)
+
+<item>新しいパッケージのバージョンは上流のリリースバージョンに
+ Debian リビジョン番号 <tt>-1</tt> を付加します。
+ 例えば `<tt>0.9.13-1</tt>'。
+
+<item>この新しいバージョンの changelog エントリを
+ "New upstream release" として <file>debian/changelog</file>
+ の一番上に追加します。例えば `<tt>dch -v 0.9.13-1</tt>'。
+
+<item>報告されたバグのうち、
+ 新しい上流リリース<em>で行われた</em>変更により修正、
+ クローズされるものを changelog で簡潔に説明します。
+
+<item>報告されたバグのうち、
+ メンテナが新しい上流リリース<em>に行った</em>変更により修正、
+ クローズされるものを changelog で簡潔に説明します。
+
+<item>パッチ/マージがうまくいかなかった場合、
+ 状況を調べてどこが引っかかったのか判断します
+ (手かがりは <file>.rej</file> ファイルに残されます)。
+ ソースに適用したパッチが上流に統合されて、
+ そのパッチはもう適切ではなくなっている、ということはよくあります。
+
+<item>新しいバージョンへのアップグレードは寡黙であるべきで、
+ 表面に現れるべきではありません。(使用中のユーザが、
+ 古いバグの修正や新機能がある場合はそれに気付くのを除いて、
+ アップグレード自体に気付かないくらいが理想です)。
+<footnote>
+ アップグレードに際してパッケージが設定ファイルを適切に更新し、
+ しっかり設計した <prgn>postinst</prgn> 等によって、
+ ユーザが望まないことを<strong>しない</strong>ようにしてください!
+ そういったことが<strong>どうして</strong> Debian
+ を選ぶのか、ということにつながっています。
+
+ <p>アップグレードが、(例えば全体的に構造が変わって
+ 設定ファイルが様々なホームディレクトリに分散して)寡黙でいられない場合、
+ 最後の手段としてパッケージを安全なデフォルト設定
+ (例えばサービスの無効化) にしておき、ポリシー
+ (<file>README.Debian</file> 及び <file>NEWS.Debian</file>)
+ で規定されているように
+ しっかりした文書を付けておくことを検討してみてください。
+ でも debconf の注釈で時間を無駄にしないでね。
+ But don't bother with the debconf note.(謎過ぎ・・)
+</footnote>
+
+<item>何らかの理由で、
+ 消してしまったテンプレートファイルを追加する必要がある場合、
+ 既に "debian 化" したディレクトリで再び同じように <tt>-o</tt>
+ オプションを付けて<prgn>dh_make</prgn> を実行し、
+ 適切に編集します。
+
+<item>Debian での変更についての再評価が必要です。
+ すべきではない確固とした理由がない限り、
+ (どのような形にせよ)上流で取り込まれたものは破棄し、
+ 上流で取り込まれていないものについてはしっかり残します。
+
+<item>ビルドシステムに変更を加えた場合は、
+ (ステップ 1 で知っていてくれると助かりますが)
+ 必要に応じて <file>debian/rules</file> と
+ <file>debian/control</file> のビルド依存を更新します。
+
+</list>
+
+<item><ref id="debuild"> や <ref id="pbuilder">
+で説明しているように新しいパッケージをビルドします。
+<package>pbuilder</package> を使用するのがいいでしょう。
+
+<item>新しいパッケージが正常にビルドできるか検証します。
+
+<list compact>
+
+<item><ref id="checkit"> を実行します。
+
+<item><ref id="upgrading"> を実行します。
+
+<item><url name="Debian バグ追跡システム (BTS)"
+ id="http://www.debian.org/Bugs/";>
+ にある未修正のバグに修正済みのものが無いか再確認します。
+
+<item>.changes ファイルの内容を照合し
+ 対象のディストリビューションに間違いなくアップロードしているか、
+ 閉じるべきバグが Closes: フィールドに挙げられているか、
+ Maintainer: 及び Changed-By: フィールドが一致するか、ファイルが
+ GPG で署名されていること、等を確認します。
+
+</list>
+
+<item>パッケージ化作業において何か直すのに変更を加えた場合は、
+ 納得するまでステップ 2 に戻って繰り返します。
+
+<item>アップロードにスポンサーが必要な場合、
+ パッケージのビルドに ('<tt>dpkg-buildpackage -sa -v ...</tt>'
+ のような感じで)特別なオプションが必要であれば確実に注記し、
+ スポンサーが正常にビルドできるように確実に伝えます。
+
+<item>自分でアップロードする場合は <ref id="upload"> を実行します。
+</enumlist>
+
+ <sect id="orig-tar"><file>orig.tar.gz</file> ファイル
+
+ <p><file>debian/</file> ディレクトリの親ディレクトリに
+ <file>orig.tar.gz</file> ファイルがない、
+ 新しいソースツリーだけからパッケージをビルドしようとしているなら、
+ <file>diff.gz</file> ファイルのないネイティブなソースパッケージを
+ 意図せず作ってしまうことになります。この方法でのパッケージ化は、
+ 他のディストリビューションでは使い道のない、
+ debian 専用のパッケージにのみ適します。
+<footnote>
+ 反対意見を持つ人もいるでしょうが、Debian 専用のパッケージであっても
+ <file>debian/</file> ディレクトリは <file>orig.tar.gz</file>
+ ファイルよりも <file>diff.gz</file>
+ ファイルにある方が良いパッケージ方法となります。
+
+</footnote>
+ <p><file>orig.tar.gz</file> ファイルと <file>diff.gz</file>
+ ファイルの両方から構成される、ネイティブでないソースパッケージの作成には、
+ <ref id="dh_make"> の <prgn>dh_make</prgn> コマンドと同じように、
+ 手作業で上流の tarball をファイル名を
+ <file><パッケージ名>_<上流バージョン>.orig.tar.gz</file>
+ と変更して親ディレクトリにコピーしなければなりません。
+
+ <sect id="cvs-buildpackage"><prgn>cvs-buildpackage</prgn>
+ コマンドとその仲間
+
+ <p>パッケージ化作業の管理に、
+ ソースコード管理システムの使用を検討してみてください。
+ 最も人気のあるもののいくつかには、
+ 専用のラッパースクリプトがあります。
+<list compact>
+ <item>CVS
+ <list compact>
+ <item><package>cvs-buildpackage</package>
+ </list>
+ <item>Subversion
+ <list compact>
+ <item><package>svn-buildpackage</package>
+ </list>
+ <item>Git (git-core)
+ <list compact>
+ <item><package>git-buildpackage</package>
+ </list>
+</list>
+ <p>ここで挙げたコマンドで新しい上流リリースのパッケージ化も自動化します。
- <p>パッケージの新しいバージョンを構築したら、
- (それが New Debian revision でも New upstream release でも)
- 古いパッケージから安全にアップグレードできることを
- 検証するために、以下を実行してください。
+ <sect id="upgrading">パッケージのアップグレードの検証
+
+ <p>パッケージの新しいバージョンを構築したら、以下を実行して
+ 古いパッケージから安全にアップグレードできることを検証してください。
<list>
- <item>旧バージョンからアップグレードする
- <item>再び旧バージョンにダウングレードして、削除する
- <item>新パッケージとしてインストールする
- <item>いったん削除して、またインストールする
- <item>完全削除する
+ <item>旧バージョンからアップグレードする
+ <item>再び旧バージョンにダウングレードして、削除する
+ <item>新パッケージとしてインストールする
+ <item>いったん削除して、またインストールする
+ <item>完全削除する
</list>
+ <p>パッケージで普通ではない pre/post/inst/rm
+ スクリプトの使い方をしている場合、
+ それについてもアップグレードがうまくいくことを確認してください。
+
<p>もしあなたのパッケージが過去にリリースされたバージョンの
Debian に含まれていた場合には、多くの人々が Debian の最新の
リリース版に含まれていたバージョンのパッケージから
@@ -2096,9 +2639,11 @@
<p>公共の場で質問する前に、まずはマニュアルを読みましょう。
ここでいうマニュアルには、例えば <file>/usr/share/doc/dpkg</file>、
- <file>/usr/share/doc/debian</file>、<file>/usr/share/doc/package/*</file>
+ <file>/usr/share/doc/debian</file>、<file>&autotools-dev;</file>、
+ <file>/usr/share/doc/package/*</file>
といったディレクトリに含まれる文書や、この文書で言及されたプログラムに
- 関する man/info ページなどが含まれます。
+ 関する man/info ページなどが含まれます。<url id="&nm-home;"> と
+ <url id="&mentors-faq;"> にある情報を全て見てみてください。
<p>もしパッケージ化の作業について疑問があり、文書を読んでも
その答を見つけられない時には、Debian Mentors メーリングリスト
@@ -2118,7 +2663,7 @@
をじっくり調べて、そこにある文書を読み、バグレポートに効率よく
対処する方法を知る時が来たということです。その時がきたら、
開発者レファレンスの「Handling Bugs (バグの扱い)」という節、
- <file>/usr/share/doc/developers-reference/developers-reference.html/ch-bug-handling.en.html</file>
+ <file>&bughandling;</file>
を調べることを、強くお勧めしておきます。
@@ -2148,6 +2693,115 @@
まだまだやるべきことがいっぱい残っています。
(もう一度言いますが、<em>ちゃんとした文書</em> を読んで勉強しましょう)。
好運を祈ります!
+
+<appendix id="pkg-eg">例
+ <p>ここでは上流の tarball <var>gentoo-1.0.2</var>.tar.gz
+ をパッケージして <tt><var>nm_target</var></tt>
+ にパッケージ全部をアップロードします。
+
+<sect id="pkg-simple">簡単なパッケージングの例
+
+ <p>
+<example>
+$ mkdir -p <var>/path/to</var> # 新しい空のディレクトリ
+$ cd <var>/path/to</var>
+$ tar -xvzf <var>/path/from/gentoo-1.0.2</var>.tar.gz # ソース確保
+$ cd <var>gentoo-1.0.2</var>
+$ dh_make -e <var>name@xxxxxxxxxx</var> -f <var>/path/from/gentoo-1.0.2</var>.tar.gz
+... 結果が出ます
+... ソースツリーを修正
+... スクリプトのパッケージの場合は debian/control に "Architecture: all"
+... ../<var>gentoo_1.0.2</var>.orig.tar.gz は消さないで
+$ debuild
+... 警告が出ないことを確認
+$ cd ..
+$ dupload -t <var>nm_target</var> <var>gentoo_1.0.2-1</var>_i386.changes
+</example>
+
+
+<sect id="pkg-dpatch">Packaging example with the <package>dpatch</package> and the <package>pbuilder</package>
+
+<p>
+<example>
+$ mkdir -p <var>/path/to</var> # 新しい空のディレクトリ
+$ cd <var>/path/to</var>
+$ tar -xvzf <var>/path/from/gentoo-1.0.2</var>.tar.gz
+$ cp -a <var>gentoo-1.0.2</var> <var>gentoo-1.0.2-orig</var>
+$ cd <var>gentoo-1.0.2</var>
+$ dh_make -e <var>name@xxxxxxxxxx</var> -f /path/from/<var>gentoo-1.0.2</var>.tar.gz
+... 結果が出ます
+</example>
+ <file>debian/rules</file> の一部を示します。元はこんな感じです。
+<example>
+configure: configure-stamp
+configure-stamp:
+ dh_testdir
+ # パッケージを設定するコマンドをここに追加
+ touch configure-stamp
+build: build-stamp
+build-stamp: configure-stamp
+ dh_testdir
+ # パッケージをコンパイルするコマンドをここに追加
+ $(MAKE)
+ #docbook-to-man debian/gentoo.sgml > gentoo.1
+ touch $@
+clean:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp configure-stamp
+ # ビルドプロセスの後始末をするコマンドをここに追加
+ -$(MAKE) clean
+ dh_clean
+</example>
+ <package>dpatch</package> を使うように
+ <file>debian/rules</file> を以下の様に編集し、
+ <package>dpatch</package> を <file>debian/control</file> ファイルの
+ <tt>Build-Depends:</tt> 行に追加します。
+<example>
+configure: configure-stamp
+configure-stamp: patch
+ dh_testdir
+ # パッケージを設定するコマンドをここに追加
+ touch configure-stamp
+build: build-stamp
+build-stamp: configure-stamp
+ dh_testdir
+ # パッケージをコンパイルするコマンドをここに追加
+ $(MAKE)
+ #docbook-to-man debian/gentoo.sgml > gentoo.1
+ touch $@
+clean: clean-patched unpatch
+clean-patched:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp configure-stamp
+ # ビルドプロセスの後始末をするコマンドをここに追加
+ -$(MAKE) clean
+ dh_clean
+patch: patch-stamp
+patch-stamp:
+ dpatch apply-all
+ dpatch call-all -a=pkg-info >patch-stamp
+unpatch:
+ dpatch deapply-all
+ rm -rf patch-stamp debian/patched
+</example>
+ <p>これで、<prgn>dpatch-edit-patch</prgn> の助けを借りて
+ <package>dpatch</package>
+ システムでソースを再パッケージする準備が整いました。
+
+<example>
+$ dpatch-edit-patch patch 10_firstpatch
+... エディタでソースツリーを修正
+$ exit 0
+... "debuild -us -uc" としてパッケージをビルドしてみる
+... "debuild clean" としてソースをきれいにする
+... ソースがビルドできるようになるまで dpatch-edit-patch の繰り返し
+$ sudo pbuilder update
+$ pdebuild
+$ cd /var/cache/pbuilder/result/
+$ dupload -t <var>nm_target</var> <var>gentoo_1.0.2-1</var>_i386.changes
+</example>
</book>
</debiandoc>