第9章 パッケージの更新

目次

9.1. Debian リビジョンの更新
9.2. 新規のアップストリームリリースの検査
9.3. アップストリームソフトウェアの新版更新
9.4. パッケージ化スタイルの更新
9.5. UTF-8 変換
9.6. パッケージをアップグレードする際の注意点

パッケージをリリースしたなら、間もなくそれを更新する必要があります。

9.1. Debian リビジョンの更新

例えば仮に、#654321 という番号のバグレポートがあなたのパッケージ に対してファイルされ、解決可能な問題が記述されていたとしましょう。 パッケージの新しい Debian リビジョンを作成するには、以下を実行する 必要があります。

  • もしこれが新規のパッチとして記録される場合には、以下のようにします。

    • dquilt new bugname.patch としてパッチ名を設定します。

    • dquilt add buggy-file として変更されるファイルを宣言します。

    • アップストリームバグに関してパッケージソース中の問題を修正します。

    • dquilt refresh として bugname.patch に記録します。

    • dquilt header -e としてその内容記述を追加します。

  • もし既存のパッチをアップデートする場合には、以下のようにします。

    • dquilt pop foo.patch として既存の foo.patch を呼び出します。

    • 古い foo.patch 中の問題を修正します。

    • dquilt refresh として foo.patch を更新します。

    • dquilt header -e としてその内容記述を更新します。

    • while dquilt push; do dquilt refresh; done として fuzz を削除しながら全てのパッチを適用します。

  • 次に Debian changelog ファイルの先頭に新しいリビジョンを 追加します。例えばdch -iを実行するか、またはバージョンを 明示したい場合ならdch -v version-revision を実行してあなたの好きなエディタで説明を記入すると楽にできます。[83]

  • changelog の説明行に、このリビジョンで解決されたバグと、 その解決方法についての簡単な説明を記載し、Closes: #54321 と続けておきます。 これによってあなたのパッケージが Debian アーカイブ中に受け入れられた時、 アーカイブ管理ソフトウェアによって該当するバグレポートが魔法のように自動的に閉じられます。

  • 上記であなたがしたことを繰り返し、必要に応じて Debian changelog ファイルを dch で更新しながら、更なるバグ修正を行います。

  • 「完全な(再)ビルド」7章パッケージのエラーの検証 で行ったことを繰り返して下さい。

  • 一旦満足した時点で、changelog 中のディストリビューション値を UNRELEASED からターゲットディストリビューション値 unstable (もしくは場合に依っては experimental) へと変更すべきです。[84]

  • 8章パッケージをアップロードする と同様にパッケージをアップロードします。 今までと違うのは、今回の場合オリジナルソースアーカイブには 変更が無く、同じものが既に Debian アーカイブ中に存在しているため、 アップロードするファイルにはオリジナルのソースアーカイブが含まれないという点だけです。

例えばオフィシャルのアーカイブへ 1.0.1-1 のようなノーマルのバージョンをアップロードする前にパッケージングを色々試すべくローカルパッケージを作る時には要注意です。スムースなアップグレードのためには、1.0.1-1~rc1 のような文字列のバージョンの項目をchangelog に作るのがいい考えです。オフィシャルパッケージのためには、そのようなローカル変更の複数項目を単一の項目にまとめて changelog をすっきりさせてもいいです。バージョン文字列の順序に関しては 「パッケージ名とバージョン」 を参照下さい。

9.2. 新規のアップストリームリリースの検査

Debian アーカイブ用の新しいアップストリームリリースパッケージの準備をする際は、まず、新アップストリームリリースをチェックしなければなりません。

アップストリームの changelogNEWS、その他の新しいバージョンでリリースされたドキュメントを読むことから始めてください

以下のようにすれば何かおかしな事が無いかに注意を払いつつ新旧のアップストリームソース間の変更検査ができます。

$ diff -urN foo-oldversion foo-newversion

missingaclocal.m4config.guessconfig.h.inconfig.subconfiguredepcompinstall-shltmain.shMakefile.in 等の Autotools によって自動生成されるファイルへの変更は無視していい場合があります。ソースを検査するための diff を実行する前に消去してもいいです。

9.3. アップストリームソフトウェアの新版更新

もし foo パッケージが新規の 3.0 (native)3.0 (quilt) フォーマットで適正にパッケージされていれば、新規のアップストリームバージョンをパッケージスリのは基本的に旧 debian ディレクトリーを新規ソースへと移動するのみです。これは新規に展開されたソース中で tar xvzf /path/to/foo_oldversion.debian.tar.gz を実行すれば出来ます。[85] もちろん当然するべき細々としたことをする必要はあります。

  • アップストリームソースのコピーを foo_newversion.orig.tar.gz ファイルとして作成します。

  • Debian の changelog ファイルを dch -v newversion-1 を使って更新します。

    • New upstream release という項目を追加します。

    • 報告のあったバグを修正する新規アップストリームリリース中の変更点に関して簡潔に記載しバグを Closes: #バグ番号 と追記してクローズします。

    • 報告のあったバグを修正する、メンテナーによる新規アップストリームリリースへのの変更点に関して簡潔に記載しバグを Closes: #バグ番号 と追記しクローズします。

  • while dquilt push; do dquilt refresh; done として fuzz を削除しながら全てのパッチを適用します。

もしパッチやマージがクリーンに適用できない場合は、状況を精査します (.rej ファイル中にヒントがあります)。

  • もしソースにあなたが適用していたパッチがアップストリームソースに統合された場合は、

    • dquilt delete として削除します。

  • もしソースにあなたが適用していたパッチが新規アップストリームソースとぶつかる場合は、

    • dquilt push -f として baz.rej としてリジェクトを強制しながら古いパッチを適用します。

    • baz.rej の本来目指した効果を実現するように、baz ファイルを手動で編集します。

    • dquilt refresh としてパッチを更新します。

  • while dquilt push; do dquilt 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 dquilt push; do dquilt refresh; done
$ dch
... document changes made

debian/watch ファイルをwatch に記載されたように設定していれば、 wget コマンドをスキップすることが出来ます。foo-oldversion ディレクトリー中で uupdate コマンドを実行する代わりに、単に uscan(1) コマンドを実行します。こうすると魔法のように更新されたソースを見つけ、それをダウンロードし、uupdate コマンドを実行します。[86]

今まで 「完全な(再)ビルド」7章パッケージのエラーの検証8章パッケージをアップロードする の中で実行してきたことを繰り返し、更新したソースをリリースできます。

9.4. パッケージ化スタイルの更新

パッケージスタイルの 更新はパッケージ更新のために必須活動ではありません。しかし、こうすることで最新の debhelper システムと 3.0 ソースフォーマットの全能力を活用できます。[87]

  • もし何らかの理由で消去されたテンプレートファイルを追加する必要がある場合には、同一の Debian ソースツリーの中で --addmissing オプションとともに dh_make をもう一度実行してもいいです。そして、それらを適正に編集しましょう。

  • debian/rules ファイルに関して debhelper v7 dh シンタックスへとパッケージが更新されていない場合は dh を使うように更新しましょう。debian/control ファイルもそれに合わせて変更しましょう。

  • コモン Debian ビルドシステム (cdbs) による Makefile 包含メカニズムで生成された rules ファイルを dh シンタックスに更新しようとする場合には、以下を参照し DEB_* 設定変数を理解して下さい。

  • 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 システムにインポートします。[88]

  • -p0-p1-p2 を使う dpatchdbscdbs のような他のパッチシステムを用いてパッケージされ得ている場合には、http://bugs.debian.org/581186にある deb3 を用いて quilt コマンドに変換します。

  • もし --with quilt オプション付きの dh コマンドとか、dh_quilt_patchdh_quilt_unpatch コマンドを用いてパッケージされている場合には、これらを削除し新規の 3.0 (native) ソースフォーマットを使うようにします。

DEP - Debian エンハンスメント提案 を確認し、ACCEPTED (採用) となった提案を取り入れるべきです。

「アップストリームソフトウェアの新版更新」 に記載された他の作業も行う必要があります。

9.5. UTF-8 変換

アップストリームの文書が旧来のエンコーディング法にてエンコードされている場合には、それらを UTF-8 に変換するのはいいことです。

  • iconv(1) を使いプレインテキストのエンコーディングを変換します。

    iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt
    
  • w3m(1) を使用して HTML ファイルを UTF-8 のプレインテキストファイルに変換します。これを行う際には、必ず UTF-8 ロケールで実行して下さい。

    LC_ALL=C.UTF-8 w3m -o display_charset=UTF-8 \
            -cols 70 -dump -no-graph -T text/html \
            < foo_in.html > foo_out.txt
    

9.6. パッケージをアップグレードする際の注意点

パッケージをアップグレードする際の注意点は以下です。

  • changelog の旧項目を保全します (自明ですが、dch -i とするべき時に dch とした過去事例があります。)

  • 現存の Debian による変更は再評価する必要があります。(何らかの形で)アップストリームが組み込んだことは捨て、アップストリームが組み込まなかったことは残しましょう。

  • ビルドシステムに変更が加えられた場合には (アップストリームの変更を精査した際に分かっているはずですよね)、 必要に応じて debian/rulesdebian/control のビルド依存関係を更新します。

  • 現存もオープンのバグへのパッチを誰かが提供していないかを、Debian Bug Tracking System (BTS) で確認します。

  • 正しいディストリビューションへアップロードすること、 Closes フィールドに適切なバグのクローズがリストされていること、MaintainerChanged-By フィールドがマッチしていること、ファイルが GPG 署名されていること等を確実にするように、.changes ファイルの内容を確認します。



[83] 日付を要求されるフォーマットで入力するには、LANG=C date -Rを使います。

[84] もし dch -r コマンドを使ってこの最終変更をする場合には、エディターにより changelog ファイルを明示的に保存して下さい。

[85] もしパッケージ foo が旧 1.0 フォーマットでパッケージされている場合は、新規に展開されたソース中で zcat /path/to/foo_oldversion.diff.gz|patch -p1 を実行すれば出来ます。

[86] もし uscan コマンドが更新されたソースはダウンロードするが uupdate コマンドを実行しない場合には、URLの最後に debian uupdate となるように debian/watch ファイルを修正するべきです。

[87] もしあなたのスポンサーや他のメンテナーが既存のパッケージスタイル更新に異存がある場合には、更新することもまたその議論することは意味がありません。他にするべきより重要なことがあります。

[88] splitdiff コマンドを用いると big.diff は多くの小さな増分パッチに分割できます。