目次
パッケージをリリースしたなら、すぐにそれを更新する必要があります。
例えば仮に、#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
を実行してあなたの好きなエディタで説明を記入すると楽にできます。[77]
version
-revision
changelog の説明行に、このリビジョンで解決されたバグと、その解決方法についての簡単な説明を記載し、Closes:
#54321
と続けておきます。これによってあなたのパッケージが Debian
アーカイブ中に受け入れられた時、アーカイブ管理ソフトウェアによって該当するバグレポートが魔法のように自動的に閉じられます。
上記であなたがしたことを繰り返し、必要に応じて Debian changelog
ファイルを
dch
で更新しながら、更なるバグ修正を行います。
「完全な(再)ビルド」 と 7章パッケージのエラーの検証 で行ったことを繰り返して下さい。
一旦満足した時点で、changelog
中のディストリビューション値を
UNRELEASED
からターゲットディストリビューション値
unstable
(もしくは場合に依っては experimental
)
へと変更すべきです。[78]
Upload the package as in 9章パッケージをアップロードする. The difference is that this time, the original source archive won't be included, as it hasn't been changed and it already exists in the Debian archive.
One tricky case can occur when you make a local package, to experiment with
the packaging before uploading the normal version to the official archive,
e.g.,
.
For smoother upgrades, it is a good idea to create a
1.0.1
-1
changelog
entry with a version string such as
.
You may unclutter 1.0.1
-1~rc1
changelog
by consolidating such local
change entries into a single entry for the official package. See 「パッケージ名とバージョン」 for the order of version strings.
When preparing packages of a new upstream release for the Debian archive, you must check the new upstream release first.
アップストリームの changelog
や
NEWS
、その他の新しいバージョンでリリースされたドキュメントを読むことから始めてください
以下のようにすれば何かおかしな事が無いかに注意を払いつつ新旧のアップストリームソース間の変更検査ができます:
$ diff -urNfoo
-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
/
を実行すれば出来ます。[79]
もちろん当然するべき細々としたことをする必要はあります:
path
/to
/foo
_oldversion
.debian.tar.gz
アップストリームソースのコピーを
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 sourcefoo
... dpkg-source: info: extractingfoo
infoo
-oldversion
dpkg-source: info: unpackingfoo
_oldversion
.orig.tar.gz dpkg-source: info: applyingfoo
_oldversion
-1.debian.tar.gz $ ls -Ffoo
-oldversion
/foo
_oldversion
-1.debian.tar.gzfoo
_oldversion
-1.dscfoo
_oldversion
.orig.tar.gz $ wget http://example.org/foo
/foo
-newversion
.tar.gz $ cdfoo
-oldversion
$ uupdate -vnewversion
../foo
-newversion
.tar.gz $ cd ../foo
-newversion
$ while dquilt push; do dquilt refresh; done $ dch ... document changes made
debian/watch
ファイルを「watch
」
に記載されたように設定していれば、 wget
コマンドをスキップすることが出来ます。
ディレクトリー中で uupdate コマンドを実行する代わりに、単に uscan(1)
コマンドを実行します。こうすると魔法のように更新されたソースを見つけ、それをダウンロードし、uupdate
コマンドを実行します。[80]
foo
-oldversion
今まで 「完全な(再)ビルド」 、 7章パッケージのエラーの検証 、9章パッケージをアップロードする の中で実行してきたことを繰り返し、更新したソースをリリースできます。
パッケージスタイルの更新はパッケージ更新のために必須活動ではありません。しかし、こうすることで最新の debhelper
システムと 3.0
ソースフォーマットの全能力を活用できます。[81]
もし何らかの理由で消去されたテンプレートファイルを追加する必要がある場合には、同一の 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
のローカルコピー
ファイル無しの
foo
.diff.gz1.0
ソースパッケージの場合、3.0 (native)
と言う内容の
debian/source/format
を作成することで新規の 3.0
(native)
ソースフォーマットに更新できます。残りの debian/*
ファイルは単にコピーするだけです。
ファイルありの
foo
.diff.gz1.0
ソースパッケージの場合、3.0 (quilt)
と言う内容の
debian/source/format
を作成することで新規の 3.0
(quilt)
ソースフォーマットに更新できます。残りの debian/*
ファイルは単にコピーするだけです。必要な場合、filterdiff -z -x '*/debian/*'
コマンドにより生成される
foo
.diff.gz > big.diffbig.diff
ファイルをあなたの quilt
システムにインポートします。[82]
-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 (採用) となった提案を取り入れるべきです。
「アップストリームソフトウェアの新版更新」 に記載された他の作業も行う必要があります。
アップストリームの文書が旧来のエンコーディング法にてエンコードされている場合には、それらを UTF-8 に変換するのはいいことです。
iconv(1) を使いプレインテキストのエンコーディングを変換します。
iconv -f latin1 -t utf8foo_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
Here are a few reminders for updating packages:
changelog
の旧項目を保全します (自明ですが、dch -i
とするべき時に dch
とした過去事例があります。)
現存の Debian による変更は再評価する必要があります。(何らかの形で)アップストリームが組み込んだことは捨て、アップストリームが組み込まなかったことは残しましょう。
ビルドシステムに変更が加えられた場合には (アップストリームの変更を精査した際に分かっているはずですよね)、 必要に応じて
debian/rules
と debian/control
のビルド依存関係を更新します。
現存もオープンのバグへのパッチを誰かが提供していないかを、Debian Bug Tracking System (BTS) で確認します。
正しいディストリビューションへアップロードすること、 Closes
フィールドに適切なバグのクローズがリストされていること、Maintainer
と
Changed-By
フィールドがマッチしていること、ファイルが GPG
署名されていること等を確実にするように、.changes
ファイルの内容を確認します。
[77] 日付を要求されるフォーマットで入力するには、LANG=C date -R
を使います。
[78] もし dch -r
コマンドを使ってこの最終変更をする場合には、エディターにより
changelog
ファイルを明示的に保存して下さい。
[79] もしパッケージ
が旧
foo
1.0
フォーマットでパッケージされている場合は、新規に展開されたソース中で zcat
/
を実行すれば出来ます。 path
/to
/foo
_oldversion
.diff.gz|patch
-p1
[80] もし uscan コマンドが更新されたソースはダウンロードするが
uupdate コマンドを実行しない場合には、URLの最後に debian
uupdate
となるように debian/watch
ファイルを修正するべきです。
[81] もしあなたのスポンサーや他のメンテナーが既存のパッケージスタイル更新に異存がある場合には、更新することもまたその議論することは意味がありません。他にするべきより重要なことがあります。
[82]
splitdiff コマンドを用いると big.diff
は多くの小さな増分パッチに分割できます。