[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
パッケージをリリースしたなら、間もなくそれを更新する必要があります。
例えば仮に、#54321 という番号のバグレポートがあなたのパッケージ に対してファイルされ、解決可能な問題が記述されていたとしましょう。 パッケージの新しい Debian リビジョンを作成するには、以下を実行する 必要があります。
もしこれが新規のパッチとして記録される場合には、以下のようにします。
"quilt new bugname.patch" としてパッチ名を設定します。
"quilt add buggy-file" として変更されるファイルを宣言します。
アップストリームバグに関してパッケージソース中の問題を修正します。
"quilt refresh" として
bugname.patch
に記録します。
"quilt header -e" としてその内容記述を追加します。
もし既存のパッチをアップデートする場合には、以下のようにします。
"quilt pop foo.patch" として既存の
foo.patch
を呼び出します。
古い foo.patch
中の問題を修正します。
"quilt refresh" として
foo.patch
を更新します。
"quilt header -e" としてその内容記述を更新します。
"while quilt push; do quilt refresh; done" として fuzz を削除しながら全てのパッチを適用します。
次に Debian changelog
ファイルの先頭に新しいリビジョンを
追加します。例えば「dch
-i」を実行するか、またはバージョンを
明示したい場合なら「dch -v
<version>-<revision>」
を実行してあなたの好きなエディタで説明を記入すると楽にできます。
changelog の説明行に、このリビジョンで解決されたバグと、 その解決方法についての簡単な説明を記載し、 「Closes: #54321」と続けておきます。 これによってあなたのパッケージが Debian アーカイブ中に受け入れられた時、 アーカイブ管理ソフトウェアによって該当するバグレポート (今回の場合は #54321) が自動的に閉じられます。
上記であなたがしたことを繰り返し、必要に応じて Debian
changelog
ファイルを "dch"
で更新しながら、更なるバグ修正を行います。
これまで 完全な(再)構築, 第 6.1 節、パッケージのエラーの検証, 第 7 章、 パッケージをアップロードする, 第 8 章 の中で実行してきたことを再度繰り返します。 今までと違うのは、今回の場合オリジナルソースアーカイブには 変更が無く、同じものが既に Debian アーカイブ中に存在しているため、 upload するファイルにはこのファイルが含まれないという点だけです。
Debian アーカイブ用の新しい上流リリースパッケージの準備ができたら、まず、上流リリースをチェックしなければなりません。
上流の changelog
や
NEWS
、その他新しいバージョンでリリースされたドキュメントを読むことから始めてください
以下のようにすれば新旧のアップストリームソース間の変更を検査を何かおかしな事が無いかに注意しつつできます。
$ diff -urN foo-oldversion foo-newversion
missing
や aclocal.m4
や config.guess
や config.h.in
や config.sub
や
configure
や depcomp
や install-sh
や
ltmain.sh
や Makefile.in
等の Autotools
によって自動生成されるファイルへの変更は無視していい場合があります。ソースを検査するための
diff
を実行する前に消去してもいいです。
もし foo
パッケージが新規の 3.0
(native) や 3.0 (quilt)
フォーマットで適正にパッケージされていれば、新規のアップストリームバージョンをパッケージスリのは基本的に旧
debian
ディレクトリを新規ソースへと移動するのみです。これは新規に展開されたソース中で
"tar xvzf
/path/to/foo_oldversion.debian.tar.gz"
を実行すれば出来ます。[54]
もちろん当然するべき雑用をする必要があります。
アップストリームソースのコピーを
foo_newversion.tar.gz
ファイルとして作成します。
Debian の changelog
ファイルを "dch -v
newversion-1" を使って更新します。
"New upstream release" という項目を追加します。
報告のあったバグを修正する新規アップストリームリリース中の変更点に関して簡潔に記載しバグをクローズします。
報告のあったバグを修正する、メンテナによる新規アップストリームリリースへのの変更点に関して簡潔に記載しバグをクローズします。
"while quilt push; do quilt refresh; done" として fuzz を削除しながら全てのパッチを適用します。
もしパッチやマージがクリーンに適用できない場合は、状況を精査します
(.rej
ファイル中にヒントがあります)。
もしソースにあなたが適用していたパッチがアップストリームソースに統合された場合は、
"quilt delete" として削除します。
もしソースにあなたが適用していたパッチが新規アップストリームソースとぶつかる場合は、
"quilt push -f" として
baz.rej
としてリジェクトを強制しながら古いパッチを適用します。
baz.rej
の本来目指した効果を実現するように、baz
ファイルを手動で編集します。
"quilt refresh" としてパッチを更新します。
"while quilt push; do quilt refresh; done" まで戻り継続します。
このプロセスは uupdate(1)
コマンドを以下のように使うことで自動化できます:
$ apt-get source foo ... dpkg-source: info: extracting foo in foo-oldversion dpkg-source: info: unpacking foo_oldversion.orig.tar.gz dpkg-source: info: applying foo_oldversion-1.debian.tar.gz $ ls -F foo-oldversion/ foo_oldversion-1.debian.tar.gz foo_oldversion-1.dsc foo_oldversion.orig.tar.gz $ wget http://example.org/foo/foo-newversion.tar.gz $ cd foo-oldversion $ uupdate -v newversion ../foo-newversion.tar.gz $ cd ../foo-newversion $ while quilt push; do quilt refresh; done $ dch ... document changes made
debian/watch
ファイルをwatch
ファイル, 第 5.20
節に記載されたように設定していれば、 wget
コマンドをスキップすることが出来ます。foo-oldversion
ディレクトリ中で uupdate
コマンドを実行する代わりに、単に uscan(1)
コマンドを実行します。こうすると魔法のように更新されたソースを見つけ、それをダウンロードし、uupdate
コマンドを実行します。[55]
今まで 完全な(再)構築, 第 6.1 節、 パッケージのエラーの検証, 第 7 章、パッケージをアップロードする, 第 8 章 の中で実行してきたことを繰り返し、更新したソースをリリースできます。
パッケージスタイルの 更新はパッケージ更新のために必須活動ではありません。しかし、こうすることで最新の
debhelper
システムと 3.0
ソースフォーマットの全能力を活用できます。[56]
もし何らかの理由で消去された雛形ファイルを追加する必要がある場合には、同一の
Debian ソースツリーの中で --addmissing
オプションとともに dh_make
をもう一度実行してもいいです。そして、それらを適正に編集しましょう。
debian/rules
ファイルに関して debhelper
V7
dh
シンタックスへとパッケージが更新されていない場合は
dh
を使うように更新しましょう。debian/control
ファイルもそれに合わせて変更しましょう。
Common Debian Build System (cdbs
) という Makefile
包含メカニズムを使った rules
から dh
シンタックスへと更新したい場合には、/usr/share/doc/cdbs/cdbs-doc.html
を参照し、その DEB_*
設定変数を理解しましょう。[57]
foo.diff.gz
ファイル無しの 1.0
ソースパッケージの場合、"3.0 (native)"
と言う内容の debian/source/format
を作成することで新規の 3.0 (native)
ソースフォーマットに更新できます。残りの
debian/*
ファイルは単にコピーするだけです。
foo.diff.gz
ファイルありの 1.0
ソースパッケージの場合、"3.0 (quilt)"
と言う内容の debian/source/format
を作成することで新規の 3.0 (quilt)
ソースフォーマットに更新できます。残りの
debian/*
ファイルは単にコピーするだけです。必要な場合、"filterdiff
-z -x '*/debian/*' foo.diff.gz > big.diff"
コマンドにより生成される big.diff
ファイルをあなたの quilt
システムにインポートします。[58]
-p0 や -p1 や -p2 を使う
dpatch
や dbs
や cdbs
のような他のパッチシステムを用いてパッケージされ得ている場合には、http://bugs.debian.org/581186
にある
deb3
を用いて quilt
コマンドに変換します。
もし "--with quilt" オプション付きの
dh
コマンドとか、dh_quilt_patch
と
dh_quilt_unpatch
コマンドを用いてパッケージされている場合には、これらを削除し新規の
3.0 (native)
ソースフォーマットを使うようにします。
上流ソフトウェアの新版更新, 第 9.3 節に記載された他の作業も行う必要があります。
パッケージをアップグレードする際の注意点は以下です。
changelog
の旧項目を保全します
(自明ですが、"dch -i" とするべき時に
"dch" とした過去事例があります。)
現存の Debian による変更は再評価する必要があります。(何らかの形で)アップストリームが組み込んだことは捨て、アップストリームが組み込まなかったことは残しましょう。
ビルドシステムに変更が加えられた場合には
(アップストリームの変更を精査した際に分かっているはずですよね)、
必要に応じて debian/rules
と debian/control
のビルド依存関係を更新します。
現存のバグへのパッチを誰かが提供していないかを、Debian Bug Tracking System
(BTS)
で確認します。
正しいディストリビューションへアップロードすること、
Closes
フィールドに適切なバグのクローズがリストされていること、Maintainer
と Changed-By
フィールドがマッチしていること、ファイルが
GPG-サインされていること等を確実にするように、.changes
ファイルの内容を確認します。
[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
Debian 新メンテナガイド
version 1.2.25, 2010-12-21 14:06:56 UTCjoy-mg@debian.org
nabetaro@debian.or.jp
yyatsuo@gmail.com
uwabami@gfd-dennou.org
lurdan@gmail.com
osamu@debian.org