[debian-users:09061] Re: Source Package

[Taketoshi Sano <sano@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

佐野＠浜松です。

# さきほど、メールを送ったつもりになっていたのですが、
# From アドレスが自宅設定用のままになってました。 _O_

むつみさん：
In message <19981014191743S.ishikawa@xxxxxxxxx>,

>  言いたいことはわかりますが、いくつか事実誤認、不明瞭な点を
> 指摘しておきます。

ありがとうございます。

> >>   しかし、現状の .orig.tar.gz では展開後に
> >>   package-upstream-version.orig という
> >>   ディレクトリに入ることが規定されているため、
>
>  ダウト。package-upstream-version になってもいいはず。よって、
> 
> >>   上流コードのアーカイブそのままでは
> >>   使えず、パッケージ作成時に tar し直す必要がある。 ( tar し直す際に gzip -9 に
> >>   よって圧縮することが徹底される、という利点はあるかもしれない。)
> 
>  かならずしも、そうなるとは限りません。

了解しました。「上流コードのアーカイブそのまま」でも
使える場合がある、ということですね。

すべての場合に「そのまま使える」わけでは無いと思っていますが、
これも誤解でしょうか ?

# この件についても、しばらく保留にさせてもらって、最新の開発環境を
# 自分で使える状態にして確認したほうが良さそうですね。

>  ちょっと、この例がわからないです。「Mule のように上流コードは
> 複数の段階にわかれていた」ってのは一体何を意味してるんですか?
> 
>  Mule-2.3 は mule-2.3.tar.gz 単体でコンパイルできましたが。
...
>  Emacs + Mule のような構成ってなんですか? Mule を version アップ
> したなら、Mule だけ upload すれば良いと思うんだけど。???

すみません。例が例になっていなかったようで。手元の bo 版に
   It was downloaded from
   (emacs) prep.gnu:/gnu/emacs-19.34b.tar.gz
   (mule)  ftp.jaist.ac.jp:/pub/gnu/mule/.alpha/mule-23-1934-alpha01.diff.gz
と書いてあったのを見たので、 emacs archive + mule patch という方法で
作成されているのかと勘違いしました。 mule 自体は README.Mule に

  Mule is free software distributed either as patches to GNU Emacs
  (19.28) or as a complete tar file. 

とあるように、 complete tar file での配布がされているんですね。

>  メンテナのひとりとしての感想としては、とりあえず、その辺は
> あんまり負荷になってません。

御意見ありがとうございます。参考になります。

>  メンテナが管理しているパッケージは高々数個です。それに対して ftp の
>  メンテナが相手をするのは、パッケージメンテナ全員とパッケージ全部です。
> 
>  現状でさえ ftp メンテナひとりに負荷が集中しているのに、さらにその負荷
> を増すような方法は、好ましいとは思えません。
> 
>  そういう負荷を増やさないためなら、メンテナのひとりとしては(多少手間
>  でも)、orig.tar.gz を upload することを選びます。

たしかに、 ftp メンテナの負荷が増えるようでは問題が大きいと思います。

ところで、現状でも場合によってはメンテナ側が近い (回線の太い) 場所に
パッケージを置いて、 ftp メンテナがネットワーク経由でそれを取りに行く
ことが、すくなくとも JP では行なわれていたこともあるように思います。

そうした場合に、例えば .dsc ファイルだけを専用の ML に送って、それを
 ftp メンテナーが特定のスクリプトで受信すれば、自動的にネットワーク
経由で取りに行ける仕組、とかいうのがもし実現できたら便利じゃないかな、
と思うのです。この場合、 .orig.tar.gz の構成物だけでなく、 .diff.gz
についても記述する必要が生じてきますけれども。

> >>      ソースパッケージをダウンロードしたければ、とりあえず
> >>      .dsc と .diff.gz を入手する。 .dsc ファイルに書かれている
> >>      .orig.tar.gz の構成物が、もし手元にあればそのまま使用できるし、
> >>      もし無ければ、その上流コードがミラーされているところならどこでも、
> >>      ( debian のミラーサイト以外からでも) 近いところから探して
> >>      入手すれば良い。
> 
>  こっちは、賛成します。要するに、FreeBSD の port とかに近い感覚ね。

そうなんですが、けっして「 ports に近い」からそれがイイ、と考えて
いるわけではありません。 (この点は、むつみさんにも、また他の多くの
方にもたぶん御理解頂けていると思いますが、念のため)

 FreeBSD の ports システム自体は、移植作業が便利なように作られて
いますが、 ports/package というパッケージ管理システムをベースと
しているようです。
で、この package による管理システムは、パッケージ間の依存関係だけ
はとりあえず面倒見るようですが、排他関係や推奨関係などは考慮しない
など、 deb パッケージシステムの持つ機能に及ばない点もいろいろある
ようです。

なので、 ports システムそのものを Debian に持ってきても、あまり
嬉しくないのでは、と思います。

しかし、 ports システムの持つ利点のうち、「自分でカスタマイズ
してインストールする際に、何を使ってどうやってパッケージを
作っているのか、理解しやすい」「そのために、自分で別のパッチ
を入れたり、使うパッチを入れ換えたりする作業が簡単」という点は
 Debian のソースパッケージを扱う仕組に取り入れても良いのでは
ないか、と思うのです。

具体的に例を挙げると、むつみさんが作成されている、 slink-jp にある
 xfree86-xtt_3.3.2.3a-1.xtt.5 では、 .orig.tar.gz には XFree86 の
 X332src-[123].tgz と 3.3.2-patch[123] だけが含まれていて、
その他の NeoMagic パッチ、 C&T パッチ、 X-TT パッチなどはすべて
 debianized patch である .diff.gz に入っていますよね。

もちろん、そうするのが悪いと批判したいわけではありません。これは
現状の枠組の中ではそうするのがベストだとむつみさんが判断した結果
でしょうし、その判断は尊重されるべきだと思います。

ただ、もし枠組を変更することで、たとえば .orig.tar.gz の構成物を
それぞれ別に置くのと同様に、 NeoMagic パッチや C&T パッチなども
 debianized patch と別にそれぞれ独立して置くことができて、しかも
それらから debianized source tree を作成する手順がどこかに記述
されており、 dpkg-source コマンドの使用によってコマンド一発で
これら複数の構成物から debianized source tree を作成できる仕組が
用意できるのなら、そしてその枠組の変更によって ftp メンテナーに
かかる負担が増えないような仕組を用意できるのなら、例えば自分の
環境に合わせたプライベートパッケージを作ろうとか、現状 .diff.gz
に含まれているパッチのうち一部を取捨選択したり、入れ換えたりして
いこうとした時に、またメンテナーが交代した際などに、役に立つのでは
ないかと思うのです。

プライベートパッケージの作成は、「パッケージの作成」という
作業に慣れる練習として、すくなくともパッケージ作成に使う
コマンドに慣れるという意味では有効じゃないかな、と思うので、
それが簡単にできるようにしていくことは、パッケージメンテナーの
人数を増やすことにもプラスなんではないかと思います。

# これも「考えが浅い」のかもしれません。御意見お願いします。

P.S.
ちょっといろいろと時間が詰まってきたので、しばらく反応が遅く
なるかもしれません。すみませんが、よろしくお願いします。

-- 
 <sano@xxxxxxxxxxxxxxxxxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)