[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:17474] Re: パッチが Debian 特有かどうかの判断を自動的にはできないか(またはできるようにしないか)



こんにちは、小林です。

2008/10/19 11:06 Nobuhiro Iwamatsu <iwamatsu@xxxxxxxxxxx>:
> On Fri, 17 Oct 2008 19:05:34 +0900
> Hideki Yamane <henrich@debian.or.jp> wrote:
>> dpatch や quilt ではパッチ管理をしていますが、このパッチが Debian 特有
>> (つまり upstream での適用を意図していないもの)であるかどうかを判別する
>> ことはできますか?
>
> 私は Debian のパッチとして入っているものは、すべて Debian に特有のパッチになる
> と思っています。なので、入っている時点で解は出ていると思います。
> もちろん、ここに書いてある upstream での適用を意図していないものも含みます。
> あくまで、その Debian バージョンでは、ということになりますが。
>
>>
>> もし現在できないとしたら、例えばパッチに行を追加して
>>
>> > ## browsers.cpp.dpatch by Hideki Yamane (Debian-JP) <henrich@debian.or.jp>
>> > ##
>> > ## All lines beginning with `## DP:' are a description of the patch.
>> > ## DP: add web browsers to the list
>> > ## Debian-Specific: yes
>> >
>> > @DPATCH@
>> > ...
>>
>> という様に Debian-Specific: のような行を追加して判断するのはどうでしょうか。
>>
>> #上記の例では、他のディストリビューションでは取り扱わないブラウザを
>> 追加している (iceweasel や風博士など) ので、upstream へのマージは
>> しないパッチです。
>>
>> なんでこんなことを提案するかというと、先日の OpenSSL 問題など、upstream
>> へのマージをもっと働きかけておけばチェックできたであろう distribution specific
>> である必要が無いパッチがまだあるだろう、という考えが浮かんだからです。
>
> Debian-Specific: yes なものは、Debian 特有のパッチで、ないもの( or no )なものは
> Upstream に返す必要があるパッチ、ということでよろしいでしょうか。

やまねさんの記述「upstream での適用を意図しているかいないか」に、
岩松さんの解釈「upstreamに返す必要があるかいないか」は合っていると思います。
しかし、自分はむしろ、「upstreamに入った変更か否か」で切り分けるべきではないかと思います。

パッチが行ベースなので、もちろんパッチを移植することに意味があるかどうかは厳密には不明ですが、
それはさておき、
とりあえずupstream (新バージョンなりVCSのメインツリーなりリリースブランチなり) に入った変更が
パッチとしてDebianに入った場合、それは「upstreamのお墨付きを得ている」と言えるので、
意味があると思います (もちろん、厳密にいえば変更が他の変更と関わっている可能性もあるので、
それで安心しすぎるのは危険ですが)。
特に修正については、コードを熟知したupstreamが取り込んだもののほうが安心できると思います。
一方で完全にDebianのための変更、
あるいはupstreamの修正内容がそのままでは当たらないので多少なりとも手を加えた変更には、
それなりに注意を払う必要があります。

特に今のようなフリーズ下の状況だと、
「新しいバージョンでの修正内容を見てそれを移植」というのは、
多くのメンテナがよくやっているかなと思います。

upstreamでの運用を意図した変更でもupstreamにrejectされることはあるし、
パッチをレビューしてもらってアドバイスをもらって再投稿というのはよくあるので、
「upstreamに返す予定」だけでは必ずしも信頼性は高くないと思います。

> 個人的な考えですと、パッチにマーキングしなくても、パッチ全部送るという手があると
> おもうのですが、いかがでしょうか。
> で、取り込まれなかったり、交渉がうまくいかなかったら、パッチはそのままDebian パッケージ
> の中に残ったままになると。
> 今はそんな感じで動いているとおもうのですが、ちがうのかな。Debian 社会契約 第2項があるので。
>
>>
>> 現状、http://patch-tracking.debian.net のような取り組みもあるようですが、
>> パッチじゃないものまでまとめて見ちゃってるのでまだまだ使い勝手が良くは
>> ありません。
>>
>> もう少し機械的に判別するためには
>> ・upstearm でマージすべきかかどうかの情報
>> を含んでいた方が楽かと思いました。
>>
>> #その情報がまだ無いとしたら、そもそもそのパッチはチェック自体がされていない
>> という証拠にもなります。
>
> やりたいことは、Debian のパッチが Upstream に送ったか、をトラッキング
> する方法はないか、ということだとおもうのですが、いかがでしょうか。
> やまねさんの提案は良いんですけど、パッチを送ったかどうかまでの判断はできないですよね。
>
> 例えば、パッケージにパッチを入れる際には、BTSとMLへのURLを changelog に書いておかない
> とだめ、とか。それを lintian でチェックするなどのシステムがいいかな、と思いました。
> # URL が正しいかはおいといて。

dpatchでもquiltでも、パッチのヘッダにコメントを書けますよね。
少なくとも自分はそれをきちんと書くようにしていますし、
おそらくそうしているのが普通のメンテナだと思います。
「きちんと」というのは、
「パッチのauthor」「upstreamに取り込まれている場合はコミットを示すリビジョン番号など」
「議論があった場合はその参照先」「パッチの意図」を明記する、という意味です。
これはVCSでのコミットログを書くのと同じ感覚ですよね。

自動的にtrackingしたいのは分かるんですが、
上に書いた様に「ちょっと改変」のような場合もあるので、
yes/noで二分してしまうのはどうかな、とちょっと考えています。

Have a nice day,

-nori