[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:09030] Source Package (Re: Pristine Upstream Source)
佐野＠浜松です。
# レスポンス遅くてすみません。休みを狭んだり、仕事が迫ったりで
# その都度書くことができずにいます。長くなってしまってごめんなさい。
こちらの件についても、まだ自分でもスッキリしていない部分もあるので、
まずはこちらの ML で相談させて頂きたいと思います。
まず、私自身が現在考えていることを説明します。
A) 前提：
ソースパッケージの構成として、現在では
filename.dsc : Debian ソース管理ファイル
filename.tar.gz : オリジナルソースアーカイブ
filename.diff.gz (もしあれば) : Debian 化の diff
という形式が推奨されている。(Debian Packaging Manual 3.1.1 より)
ここで filename.tar.gz はパッケージが Debian 固有のコードによる
もので無い場合 (Debian 化の diff が存在する場合)
package_upstream-version.orig.tar.gz という名称が付けられている。
(Debian Packaging Manual 3.3 より)
ちなみに、古いバージョンの形式では、単に
filename.tar.gz
filename.diff.gz (必要なら)
という構成であり、 filename.tar.gz だけで Debian 化されたソース
ツリーを完全に含むものであった。
B) 疑問：
上記の構成は、現状で「最良の選択」だろうか ?
「古いバージョンの形式」では .tar.gz のみを入手することで Debian 化
されたソースツリーを得ることができる点で「単純」ではあった。
しかし、「上流コード」によっては「ソースコードを変更しての配布は、パッチ
を添付するという形でのみ許可」という制限が付されたものもあることから、
(Debian Policy Manual 2.1.1 DFSG, 4 Integrity of The Author's Source Code
には The license may restrict source-code from being distributed in
modified form only if the license allows the distribution of ``patch files''
with the source code for the purpose of modifying the program at build time.
という記載があり、このような制限を意識していることが示されている。)
現在のように .orig.tar.gz と .diff.gz を別にする構成が必要になったものと
推察できる。
しかし、現状の .orig.tar.gz では展開後に package-upstream-version.orig という
ディレクトリに入ることが規定されているため、上流コードのアーカイブそのままでは
使えず、パッケージ作成時に tar し直す必要がある。 ( tar し直す際に gzip -9 に
よって圧縮することが徹底される、という利点はあるかもしれない。)
また、 Debian 化の diff ではいろいろと制限があるため、たとえば (過去の例ですが)
Mule のように「上流コード」が複数の段階に分かれている場合、パッケージ作成時に
それらをまとめたものを .orig.tar.gz として作成し直すことになる。
作成時の「手間」という面では、実際にはたいしたことは無いだろう。
しかし、例えば Emacs + Mule のような構成で、 Mule の部分だけバージョン
アップした時など、現状では Emacs 部分のコードを含む .orig.tar.gz 全体を
アップロードし直さなければならない。
もし、これが Mule パッチの部分と、 .dsc および .diff.gz のみ送れば
済むようになれば、それはメンテナーに対する負荷を下げることにならないか。
さらに、 .orig.tar.gz を構成する (既存の) コードの入手方法、および
それらから .orig.tar.gz を構成する方法、を (例えば) .dsc ファイル中
に記述することで、
メンテナーは .dsc と .diff.gz のみを送れば良く、
ftp サイトの管理者側で適当なコマンドを使用することで
(現状 mv コマンドを使ってソースパッケージ構成ファイルをアップロード
された場所から適切な場所に移動するのと同程度な手間で)
ネットワーク上から .orig.tar.gz の構成物を入手し、
ftp サイトに置いておける
ソースパッケージをダウンロードしたければ、とりあえず
.dsc と .diff.gz を入手する。 .dsc ファイルに書かれている
.orig.tar.gz の構成物が、もし手元にあればそのまま使用できるし、
もし無ければ、その上流コードがミラーされているところならどこでも、
( debian のミラーサイト以外からでも) 近いところから探して
入手すれば良い。
ようになっていれば、より望ましい姿とは言えないだろうか。
もちろん、このためには dpkg-source コマンド自体も変更する必要があるし、
各種のドキュメント類も改訂する必要があり、かなりの手間が予想される。
が、上記のような仕組が用意できれば、松本さんの書かれた
> アプリケーションによっては「アーカイブ全体を AS IS でね」というものも
> ありますし、例えば GPL モノなら「変更点は明記すべし」という制限も
> かかりますよね。
ということは明確にクリアできるし、
> # 技術的にも、メンテナが変わったときに困らないかな…。
> # 例えばメンテナが消息不明になって誰かが引き継ぎたいときに、
> # 「こりゃどのソースにどのパッチを当てたんだ？」みたいに。
といった問題は生じない。
とりあえず、現在まで自分なりにいろいろ考えた結果、上記のような
ところにいきつきました。現在「スッキリしていない」のは、現状の
.orig.tar.gz にまとめるという方法は、単にそういう実装のほうが
楽だったからということなのか、それともどうしても .orig.tar.gz
にまとめるという方法で無ければ実現できないような機能上の問題が
ソースパッケージの構成に存在するのか、という点です。
この件についても、議論を通じて「結果」を得るには本家の ML に
提起する必要があるかと思います。もしこういう話を持っていく際の
窓口を御存知でしたら、そちらについてもよろしくお願いします。
ところで、前原さんの書かれた
> 最近の .orig.tar.gz は、「きれいな」ものが多いだろうと思っているのですが
> (確認したわけではありません)、私の記憶が間違っていなければ、以前は仕様の
> せいで「きれいな」ものを使うこと自体が不可能だったはずです。
>
> /usr/doc/dpkg/changelog.gz:
>
> > dpkg (1.4.0.13) experimental; urgency=low
>
> から導入された、
>
> > * Patch from Guy Maor <maor@xxxxxxxxxxxxxx> to dpkg-source.pl to support
> > pristine (MD5-equivalent) upstream sources.
>
> によって初めて可能になったというのが経緯だと思います(昨年の 5 月頃のよう
> ですね)。ですから、これをひきずっているものがあることは否定できません。
これは、 package_upstream-version.orig.tar.gz の展開後に
package-upstream-version ディレクトリに入らないものについても
利用できる、ということでしょうか。
(もしそうなら、ひょっとして上記のことも今さら私が言うまでもなく、
既に仕組としては実現されていたりするんでしょうか)
--
<sano@xxxxxxxxxxxxxxxxxxxxxxxxxx> : Taketoshi Sano (佐野 武俊)