小林儀
匡
|
|
この文書では、 まず Debian パッケージのビルドの流れと debian/rules の各ターゲットの役割を概観した上で、 debhelper や CDBS を用いて debian/rules をメンテナンスしやすくする方法を説明します。 次に、 開発元のソースコードに対する変更をメ ンテナンスしやすいかたちで加える方法として、 パッチ管理ツールである dpatch と quilt の使い方を説明し ます。
一般的な Debian パッケージの作成方法に興味のある読者を対象としています。
これまでにパッケージの作成について学んだことを整理してみましょう。 簡単にまとめてしまえば、 以下のようになるのではな いでしょうか。
一通りのパッケージ作成の流れや、 debian/rules 以外のファイルの内容は何となく分かったかと思います。 しかし、 debhelper のコマンドが連ねられている debian/rules については、 実際のところどのようなことをしており、 どのような流れ でパッケージが作られているのかは、 おそらくまだ理解できていないと思います。 また、 パッケージをさらに細かく設定し、 よ り洗練されたものにする方法も分からないでしょう。
そこで、 今回は、 debian/rules と debhelper の各コマンドの内容を説明し、 パッケージがどのような過程を経てビルドされ ているのかを明らかにします。 その上で、 debhelper や CDBS を用いて、 Debian Policy Manual (debian-policy) に準拠した パッケージをメンテナンスしやすいかたちで作成する方法を説明します。 また、 開発元のソースコードに対する変更をメン テナンスしやすいかたちで加える方法として、 パッチ管理ツールである dpatch と quilt の使い方を説明し ます。
まずビルドの流れについて見ていくことから始めましょう。
debuild などのパッケージビルドツールでは、 大まかに言うと、 一般的に次のような手順でパッケージをビルドし ます。
以 下 で こ れ ら を 詳 し く 説 明 し ま す 。
実際にビルドを始める前に、 まずはビルドのための環境を整える必要があります。
「ビルドのための環境を整える」 と一口に言っても色々とありますが、 例えばソースパッケージの展開などが挙げられます。 ソースパッケージをビルドする場合は、 ソースパッケージを展開してソースツリーの状態にするところから始めなければなりま せん。 もちろんソースツリーでビルドする場合はこれは不要です。
また、 パッケージのビルドには、 通常、 様々なもの (コンパイラやライブラリなど) が必要となるので、 ビルド中にエラーに ならないよう、 それらの存在を確認しておく必要もあります。 必要となるパッケージは、 ソースパッケージの場合は.dsc ファイ ルの Build-Depends フィールド、 ソースツリーの場合は debian/control の Build-Depends フィールドに書かれています。 ビ ルドツールによっては、 ビルドに必要なパッケージを確認するだけでなく、 インストールされていない場合にインストールして くれるものもあります。
また、 pdebuild などのように chroot 環境内でパッケージをビルドするツールは、 こういった作業の前にまず chroot 環境を 作ってそこに入るところから始めるでしょう。
必要なパッケージが揃っていることを確認したところで、 不要なファイルを削除します。 一般に、 以前のビルドで生成された ファイルがある場合はそれを削除して、 常に同じ状態からビルドできるようにすべきです。 debian/rules の clean ターゲット をそのような目的で使うよう、 debian-policy において定められています。
ソースパッケージを作成するタイミングとしては、 不要なファイルを削除した後、 バイナリパッケージに含めるファイルのビル ドに入る前が最もよいでしょう。 dpkg-sourceコマンドの-bオプションを使うと、 ソースツリーからソースパッケージを作成 できます。
ソースパッケージを作成し終えたらいよいよバイナリパッケージの作成に移ります。 バイナリパッケージの作成は大きく 2 段階 に分けることができます。 最初の段階は、 設定やコンパイルです。
C などの言語で書かれたプログラムやライブラリがパッケージに含まれている場合、 それらをインストール前にコンパイル して、 バイナリのプログラムやライブラリを作成する必要があります。 プログラムのビルドに GNU Autoconf を使用 するようになっている場合は、 コンパイルの前に configure スクリプトを走らせて設定を行う必要もあるで しょう。
この手続きは、 バイナリのプログラムやライブラリを含んでいないパッケージについても必要になることが多いでしょう。 例 えば、 LATEXや SGML などの形式で書かれたドキュメントは、 HTML や PostScript、 PDF などの配布に適した形式に変換 してバイナリパッケージに含めるべきです。 また、 ソースとなるデータを変換してインストール用のデータを作成する必要があ る場合も、 通常はここでその変換を行います。
debian-policy では、 このような、 プログラムやライブラリの設定・コンパイルやデータの変換のために、 debian/rules の build ターゲットを使うよう指定されています。
必要なファイルをすべてビルドしたところで、 それらを適切なパーミッションで適切な場所に配置し、 バイナリパッケージにま とめ上げる必要があります。 あっさりと書いてしまいましたが、 debian-policy に準拠するパッケージを手で作成しようとする 場合には、 かなり複雑で面倒な作業を要求されるプロセスです。
このプロセスは、 通常、 まず debian/tmp を/と見なしてソフトウェア全体のインストール ( 「仮インストール」 ) を行い、 その上で debian/tmp 内の各ファイルを適切に debian/< バイナリパッケージ名 > に振り分け、 最後に debian/< バイナリ パ ッケ ー ジ 名 > をそれぞれバイナリパッケージ化する、 という流れで行います。 debian/< バイナリパッケージ 名 > をバイナリパッケージ化する際には、 パーミッションの調節やファイルの圧縮など、 しなければなら ないこと、 推奨されていることが多数あります。 それらは後で詳述しますので、 ここでは詳しい説明は省き ます。
debian-policy では、 バイナリパッケージをまとめ上げるために、 debian/rules の binary ターゲットを使うよう指定されて います。
ソースパッケージとバイナリパッケージのファイルが一通り揃ったところで、 これらのファイルに関する情報 をまとめた.changes ファイルを作成する必要があります。 これには dpkg-genchanges コマンドが使用され ます。
私家版パッケージやテストビルドでは必要ありませんが、 公式パッケージにする場合は、 最後にパッケージに署 名する必要があります。 公式パッケージにしない場合でも、 広く配布する場合には署名することをお勧めし ます。
署名は、 .dsc ファイルと.changes ファイルに対して行います。 .dsc ファイルにはソースパッケージの.tar.gz ファ イルと.diff.gz ファイルのハッシュとサイズが書かれているので、 署名を施すことでこれらのファイルの品 質を保証できます。 また、 .changes ファイルにはソースパッケージとバイナリパッケージのすべてのファイ ルのハッシュとサイズが書かれているので、 署名を施すことでこれらのファイルすべての品質を保証できま す*2 。
署名には、 通常、 devscripts パッケージに含まれている debsign コマンドを使います。 このコマンドは、 最初に.dsc ファイル に対する署名を行い、 その後で、 .changes 内の.dsc ファイルのエントリのハッシュやサイズを署名後の値に置換した上 で、 .changes ファイルに署名してくれます。
ビルド手順の説明から分かるかと思いますが、 debian/rules には、 パッケージのビルド時に必要となるター ゲットがあります。 説明に登場した clean、 build、 binary の他に、 binary-arch と binary-indep も必須の ターゲットです。 以下でこれらのターゲットの役割を簡単に示します (詳細は debian-policy を参照してくだ さい)。
clean、 build、 binary については、 パッケージのトップレベルディレクトリ (debian ディレクトリの親ディレクトリ) をカレ ントディレクトリとして実行するよう定められています。
debian/rules の必須ターゲットに関する規約を簡単に眺めたところで、 実際のパッケージの debian/rules の例を見てみましょ う。 以下では、 Debian パッケージ作成用のツールを何も使わずに実装した、 hello パッケージの debian/rules から抽出した コード (を一部改変したもの) を例に示します。
まずは clean ターゲットです。
clean:
rm -f build -$(MAKE) -i distclean rm -rf *~ debian/tmp debian/*~ debian/files* debian/substvars |
簡単に読めますね。 以下のことをやっているだけです。
続いて build ターゲットです。
CC = gcc
CFLAGS = -g -Wall ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O2 endif build: ./configure --prefix=/usr $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)" touch build |
GNU Make の makefile に慣れていないと、 変数の設定の部分が分かりにくいかもしれませんが、 build ターゲット自体は非 常に単純ですね。 ソフトウェアをソースからインストールしたことのあるかたならお馴染みの、 Autoconf を用いた一般的な C プログラムのビルド方法です。
最後に、 binary、 binary-arch、 binary-indep の 3 つのターゲットです。
package = hello
docdir = debian/tmp/usr/share/doc/$(package) INSTALL_PROGRAM = install ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif binary-indep: build binary-arch: build rm -rf debian/tmp install -d debian/tmp/DEBIAN $(docdir) $(MAKE) INSTALL_PROGRAM="$(INSTALL_PROGRAM)" \ prefix=$(CURDIR)/debian/tmp/usr install cp -a NEWS debian/copyright $(docdir) cp -a debian/changelog $(docdir)/changelog.Debian cp -a ChangeLog $(docdir)/changelog cd $(docdir) && gzip -9 changelog changelog.Debian gzip -r9 debian/tmp/usr/share/man dpkg-shlibdeps debian/tmp/usr/bin/hello dpkg-gencontrol chown -R root:root debian/tmp chmod -R u+w,go=rX debian/tmp dpkg-deb --build debian/tmp .. binary: binary-indep binary-arch |
一つずつ手順を追っていけば、 以下のような手順でバイナリパッケージを生成していることが分かります。
バイナリプログラム 1 つと付随データをバイナリパッケージ 1 つにインストールするだけなのに、 かなり複雑な手順を踏ん でいます。 これは以下のような理由からです。
バイナリパッケージ 1 つを生成するパッケージでさえこれだけの手順を踏まなければならないので、 様々なファイルを複数の バイナリパッケージに分けてインストールするようなパッケージの作成に、 かなり手間がかかるのは容易に想像でき ます。
______________________________________________________________________________________________
deb ファイルの内容 dpkg-deb –build がどのようにして複数のファイルを 1 つの「パッケージ」 にまとめているか、 興味があるかもしれませ ん。 そのような場合は、 以下の実行例が参考になるでしょう。
|
debian-policy の規約に従った Debian パッケージを容易に作成できるようにしてくれるのが、 debhelper です。 例として、 先 程の hello パッケージに対して debhelper を使用した hello-debhelper パッケージの debian/rules を見てみま しょう。
まずは clean ターゲットです。
clean:
dh_clean rm -f build -$(MAKE) -i distclean |
hello パッケージの場合とほぼ同じですが、 debian ディレクトリの掃除に関してはdh_cleanというコマンドを使用している ことが分かります。
次は build ターゲットですが、 これは hello パッケージのものとまったく同じなので省略します。
最後に、 hello パッケージではかなり複雑だった、 binary、 binary-arch、 binary-indep の 3 つのターゲット です。
package = hello-debhelper
install: build dh_clean dh_installdirs $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr install binary-indep: install binary-arch: install dh_installdocs -a NEWS dh_installchangelogs -a ChangeLog dh_strip -a dh_compress -a dh_fixperms -a dh_installdeb -a dh_shlibdeps -a dh_gencontrol -a dh_md5sums -a dh_builddeb -a binary: binary-indep binary-arch |
「dh_」 で始まるコマンド群で占められているのが分かります。 これらが debhelper のコマンドです。 オプションやファイル 名の指定などは部分的にはあるものの、 基本的には非常にシンプルな記述となっており、 バイナリパッケージ名やインストール パスなどの具体的な情報を記述する必要がなくなっています。 ここでは単一のバイナリパッケージの例を取り上げていますが、 複数のバイナリパッケージを生成する debian/rules についても同様にシンプルに記述できます。 それは、 debhelper の、 以下 のような特長からです。
debhelper は、 debian/rules をメンテナンスする手間を大きく減らしてくれる、 非常に有用なツールだと言え ます。
debhelper の特長を説明したところで、 そのコマンド群を概観しましょう。 と言っても、 コマンドの役割やオプションの説明、 必要となる設定ファイルについては、 各コマンドのマニュアルページや書籍『[入門] Debian パッケージ』 に 詳しい記述があるので、 それらに譲ります。 ここでは、 大まかな分類と使い方の説明に焦点を絞った話をし ます。
debian/rules の記述を減らしてくれる debhelper ですが、 「多数のコマンドのどれをどのタイミングで使うべきか分かりにく い」 という欠点があります。 それは、 上で述べたように、 debian-policy の規約や dpkg のコマンドごとに、 debhelper にも対 応するコマンドが存在するため、 debhelper を使用しても、 deb パッケージにまとめるまでの手順は多いからです。 そこで、 こ こでは、 使用する状況によってコマンドを 7 つに分類しておきます。 debhelper で debian/rules を書く際の参考にしていただ けると幸いです。
なお、 「binary 系ターゲット」 とは、 binary、 binary-arch、 binary-indep の 3 つのターゲットのことです。
以下のコマンドは、 各ターゲットの頭において、 ターゲットを正しい条件で実行しようとしているか確認するために使われるも のです。
以下のコマンドは、 clean ターゲットで使われるものです。
以下のコマンドは、 binary 系ターゲットにおいて、 仮インストールの準備段階で実行すべきものです。
以下のコマンドは、 binary 系ターゲットにおいて、 仮インストール後にファイルなどを debian/< バイナリパッケージ名 > 以 下にインストールするのに使われます。
以下のコマンドは、 binary 系ターゲットにおいて、 debian/< バイナリパッケージ名 > 以下にインストールされたファイルを、 debian-policy に適合するよう修正するのに使われます。
以下のコマンドは、 binary 系ターゲットにおいて、 deb パッケージ生成の直前に行う処理に使用されます。
以下のコマンドは、 binary 系ターゲットにおいて、 deb パッケージ生成の直前に行う処理に使用されます。
debhelper の様々なコマンドを、 使用するタイミングによって 7 つに分類してみました。 これによって浮かび上がってくるの は、 「どのパッケージでもコマンドを呼び出す順番はほぼ同じ」 という事実です。 実際、 dh_make で作成した debian/rules の雛形をいじる場合でも、 debhelper コマンド群の呼び出し順序を変更することはほとんどないで しょう。
ここで、 「ではコマンド群の呼び出しの流れを一般化してしまえば、 debhelper のコマンドばかりが並んだ、 似たような debian/rules を量産しないで済む」 と気付くと思います。 実際問題として、 雛形から作成した、 似たような debian/rules を多 数管理するのはコストがかかります。 新しいコマンドができた場合、 それをすべての debian/rules の同じ場所に加えればなり ません。
そこで登場するのが CDBS です。 次は、 CDBS の debhelper ルールを用いて debian/rules をさらに簡潔にし ます。
「似た内容の、 短くはない debian/rules を量産する」 という debhelper の欠点を解決するのが、 CDBS の debhelper ルール (debhelper.mk) です。 CDBS とは、 debian/rules の記述をモジュール化して再利用できるようにしたものをライブラ リとして提供し、 一般的な流れに沿った debian/rules を非常に簡単に記述できるようにするシステムです。 CDBS の debhelper ルール (debhelper.mk) では、 debhelper を用いたビルドの一般的な流れが既に定義さ れているので、 debhelper の各コマンドに与えるオプションや引数を指定するだけで debian/rules が書け ます。
hello-debhelper の debian/rules を CDBS の debhelper ルールを用いて書き換えると、 次のようになり ます。
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk package = hello-cdbs CC = gcc CFLAGS = -g -Wall ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O2 endif clean:: -$(MAKE) -i distclean install/hello-cdbs:: $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr install common-configure-arch:: ./configure --prefix=/usr common-build-arch:: $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)" DEB_INSTALL_DOCS_ALL := NEWS DEB_INSTALL_CHANGELOGS_ALL := ChangeLog |
書き換えは、 以下のような手順で行いました。
以下でこれらを詳しく説明します。
debhelper ルールの定義を取り込むには、 /usr/share/cdbs/1/rules/debhelper.mkをインクルードする必要があり ます。
debhelper のコマンドは、 引数やオプションがついていないものについては削除してかまいません。 対応する操作が debhelper ルール内で定義されています。
引数やオプションがついている場合は、 その内容を変数に設定しなおす必要があります。 CDBS の debhelper ルールでは、 debhelper の各コマンドの引数やオプションに対応する変数を使用するようになっています。 変数の例を示し ます。
CDBS を使用する場合は、 ターゲットの指定に二重コロンを使用する必要があります。 これは、 モジュール化に、 「ターゲット を二重コロンで指定することで処理を多重定義できる」 という GNU Make makefile の機能を使用していためです。 以下のリ ストのように、 通常のコロンの場合は後で指定された処理が実行されますが、 二重コロンで定義すると両方の処理が実行され ます。
noritada[10:22]% cat Makefile
hoge: @echo foo hoge: @echo bar noritada[10:22]% make Makefile:5: 警告: ターゲット ‘hoge’ へのコマンドを置き換えます Makefile:2: 警告: ターゲット ‘hoge’ への古いコマンドは無視されます bar noritada[10:22]% cat Makefile hoge:: @echo foo hoge:: @echo bar noritada[10:22]% make foo bar |
CDBS の debhelper ルール*4 で は、 binary や build-arch、 build-indep などの大きな流れを表すターゲットを複数の処理に分割し、 ユーザ が処理の多重定義を用いて適切なタイミングで処理を挿入できるようにしています。 ターゲットの例を示し ます。
パッケージのビルド方法や debian/rules の各ターゲットの役割を概観した上で、 debian/rules をより簡潔 に、 より分かりやすく書く方法を求めて、 debhelper や CDBS を見てきました。 簡潔に分かりやすく書く ことはメンテナンスのしやすさに繋がるので、 できるだけ debian/rules をシンプルに保つことをお勧めし ま す 。
これまでは debian ディレクトリ以下のみをいじってきましたが、 最後に、 開発元が配布しているソースコードに修正を加える 方法を説明します。 debian/rules についてはメンテナンスのしやすさを重要視しましたが、 それは、 開発元が配布している ソースコードに修正を加える際にも当てはまります。
Debian パッケージを管理していると、 開発元のソースコードに手を加えたくなることがよくあります。 理由は様々 です。
こんなときに、 開発元のソースコードに修正を加える最も簡単な方法は、 debian ディレクトリの外側のソースコードを直接 いじることです。 ネイティブでない Debian ソースパッケージは、 .tar.gz ファイルと.diff.gz ファイル、 .dsc ファイルから成る ので、 ソースコードに変更を加えれば、 それは開発元のソースコードからの差分として.diff.gz ファイルに含まれ ます。
しかし、 この安直な方法にはもちろん大きな問題があります。
そこで、 変更を開発元のソースコードに直接加えることはせず、 dpatch や quilt を用いて、 意味的なま とまりのある単位でパッチとして管理することが推奨されています。 簡単にまとめると、 以下のような方法 です。
ここでは、 簡単にその使い方を見ていきます。
一般に、 dpatch や quilt でパッチを管理する場合は、 debian/patches ディレクトリをパッチ置き場として使用します。 dpatch の場合は debian/patches/00list が、 quilt の場合は debian/patches/series がそれぞれパッチのリストとなっており、 debian/patches に含まれている一連のパッチが、 このパッチリストに記載されている順に適用されていき ます。
dpatch を使用している kazehakase パッケージの debian/patches の例:
noritada[16:39]% ls debian/patches/*
debian/patches/00list debian/patches/05_add_missing.dpatch debian/patches/20_user_agent_tag.dpatch debian/patches/30_bookmarkbar_DSA.dpatch debian/patches/50_passwordmgr.dpatch debian/patches/60_fix_ftbfs.dpatch debian/patches/70_enable_gtk_deprecated.dpatch debian/patches/80_NSIBADCERTLISTNER.dpatch noritada[16:39]% cat debian/patches/00list 20_user_agent_tag 30_bookmarkbar_DSA 50_passwordmgr |
quilt を使用している skksearch パッケージの debian/patches の例:
noritada[16:52]% ls debian/patches/*
debian/patches/clean-build-errors-and-warnings.diff debian/patches/conf-file.diff debian/patches/db4.3.diff debian/patches/dic-bufsize.diff debian/patches/plain-search.diff debian/patches/series noritada[16:52]% cat debian/patches/series conf-file.diff db4.3.diff dic-bufsize.diff plain-search.diff clean-build-errors-and-warnings.diff |
パッチを当てるには、 dpatch の場合は dpatch apply を、 quilt の場合は quilt push を使用してください。 外すには、 dpatch の場合は dpatch deapply を、 quilt の場合は quilt pop を使用してください。
新たなパッチを作成するには、 まずパッチをどこに挟むか決めてください。 dpatch において < あるパッチ > の次に挟む場 合は、 次のように行います。
$ dpatch-edit-patch patch <新規パッチ> <あるパッチ>
$ editor <あるファイル> (パッチに含める変更を加えます) $ exit 0 |
quilt において同様の操作を行う場合は、 次のようにします。
$ quilt push <あるパッチ> (<あるパッチ>が既に当たっている場合は、 quilt pop <あるパッチ>になります)
$ quilt new <新規パッチ> $ quilt add <あるファイル> (パッチの作成を開始した後、 変更する対象は add で追加しておく必要があります) $ editor <あるファイル> (パッチに含める変更を加えます) $ quilt refresh |
変更を加えるためにエディタを使う場合は、 「quilt edit < あるファイル >」 を実行すれば、 「quilt add < あるファイ ル >」 を実行せずに編集することも可能です。
折角パッチを debian/patches に入れておいたところで、 ソースパッケージをビルドするときにはパッチを外した状態にしてお き 、 バ イ ナ リ パ ッケ ー ジ を ビ ル ド す る と き に は パ ッチ を 当 て た 状 態 に し て お か な け れ ば 、 意 味 が あ り ま せ ん 。 こ れ は 、 debian/rules でパッチに関する依存関係を適切に設定することで実現できます。 以下では、 様々な場合について、 debian/rules の記述例を示します。
まず、 dpatch についてです。 debhelper を使用している場合は、
/usr/share/doc/dpatch/examples/rules/rules.new.dh.gzを参考にしてください。
build: build-stamp
build-stamp: patch dh_testdir # ここでソフトウェアをビルドする。 touch build-stamp clean: clean1 unpatch clean1: dh_testdir dh_testroot dh_clean -k # ここで掃除をする。 patch: patch-stamp patch-stamp: dpatch apply-all dpatch cat-all >patch-stamp touch patch-stamp unpatch: dpatch deapply-all rm -rf patch-stamp debian/patched |
CDBS を利用している場合は、 CDBS のドキュメントにあるとおり、 以下のような行を加えるだけでかまいません。 ただし、 autotools.mk をインクルードしている場合は、 dpatch.mk をインクルードするのはそれよりも後ろにしてくだ さい。
include /usr/share/cdbs/1/rules/dpatch.mk
|
quilt についても、 CDBS を利用している場合は、 CDBS のドキュメントにあるとおり、 以下のような行を加えるだけでかま いません。
include /usr/share/cdbs/1/rules/patchsys-quilt.mk
|
_____________________________________________________________________________________________________________________________
パッチ管理ツールの近況と今後 Debian で長いこと使われてきたパッチ管理ツール dpatch については、 dh_makeが、 1ヶ月ほど前にバージョン 0.45 で --dpatchオプションを提供し始めました。 これまでは、 パッケージ化への入口となるdh_makeによるサポートがなかっ たため、 「パッチ管理ツールはパッケージメンテナが好みで使用するもの」 という雰囲気があったように思いますが、 今 後、 パッチ管理が普及し、 開発元のソースコードは一切いじらないという風潮が強くなるのだとしたら、 嬉しいこと です。 一方で quilt については、 昔は非常にマイナーなパッチ管理ツールでしたが、 xorg を管理する Debian X Strike Force や glibc を管理する Debian GNU Libc Maintainers など、 大規模なパッケージで高い評判が得られ、 徐々に浸透してきてい るようです。 また、 直観的なユーザインタフェースのためか、 パッケージ管理の初心者からの評判もよい ようで、 debian-mentors メーリングリストなどでもしばしば話題に出ているのを見掛けます。 Debian パッケージ以外でも様々なところで使えるツールだと思うので、 今後は認知度が高まることを期待してい ます。 さて、 このようなパッチ管理ツールですが、 将来的にはソースパッケージそのものにパッチ管理の機構が取り込まれてい くことが期待されます。 これまでは、 オリジナルからの差分を.diff.gz ファイルにすべて押し込んでいました が、 これは、 「オリジナルからの変更を分かりやすく管理する」 という観点からは非常に不便でした。 こ の問題を解決するため、 dpkg 1.14.18 では、 新たなソースパッケージの形式「3.0 (quilt)」 がサポート されました。 lenny の次のリリースから、 デフォルトかつ推奨されるソースパッケージ形式になる予定 です。 「3.0 (quilt)」 では、 ソースパッケージは以下のファイルから成ります。
注目すべきは、 これらの展開方法です。
つまり、 「debian ディレクトリ以下の追加 + 開発元のソースコードに対する変更」 から成るこれまでの.diff.gz ファイル は廃止され、 ソースコードに対する変更はパッチのかたちでしかできなくなります。 これは、 メンテナンス性を高める意 味で非常に大きな前進でしょう。 |
第 41 回東京エリア Debian 勉強会 2008 年 6 月
____________________________________________________________________________________________