第8章 パッケージの更新

# 第8章 パッケージの更新

最新の内容とより実用的な例でこの入門書を書き換えたものが Guide for Debian Maintainers として入手できます。この新しい入門書を第一次的な入門書として使ってください。

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

## 8.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`` を実行してあなたの好きなエディタで説明を記入すると楽にできます。[76]

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

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

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

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

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

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

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

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 を実行する前に消去してもいいです。

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

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

- アップストリームソースのコピーを `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 コマンドを実行します。[79]

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

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

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

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

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

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

  - `/usr/share/doc/cdbs/cdbs-doc.pdf.gz` のローカルコピー

  - The Common Debian Build System (CDBS), FOSDEM 2009

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

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

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

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

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

## 8.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=en_US.UTF-8 w3m -o display_charset=UTF-8 \
              -cols 70 -dump -no-graph -T text/html \
              < foo_in.html > foo_out.txt

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

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

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

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

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

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

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

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

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

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

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

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

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

第7章 パッケージのエラーの検証 |  | 第9章 パッケージをアップロードする