[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:09070] Re: Source Package
むつみです。
Taketoshi Sano <sano@xxxxxxxxxxxxxxxxxxxxxxxxxx> さんは
Subject: [debian-users:09061] Re: Source Package
Message-ID: <199810150310.MAA04734@xxxxxxxxxxxxxxxxxxxxxxxxx>
において言いました
>> 佐野＠浜松です。
>> 了解しました。「上流コードのアーカイブそのまま」でも
>> 使える場合がある、ということですね。
>>
>> すべての場合に「そのまま使える」わけでは無いと思っていますが、
>> これも誤解でしょうか ?
誤解ではないです。当然使えない場合はでてきます。
>> すみません。例が例になっていなかったようで。手元の 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 での配布がされているんですね。
あー。そういう話ですか。
mule って話だったんで、てっきり Mule-2.3 のことを言ってるのかと。
正式に配布されている mule に関しては complete tar file でも配布されて
います。例えば、mule-2.3.tar.gz とか
ただ、bo に採用されていた mule は正式配布の mule ではなく、「Mule-2.3
から、Emacs-19.28 に対して拡張されている部分を取出し、それを
Emacs-19.34 に当てられるようにして作った Mule-2.3 based on Emacs-19.34」
だったわけです。
つまり、佐野さんが言ってた「Emacs + Mule」ってのは、
Emacs emacs-19.34b.tar.gz
Mule mule-23-1934-alpha01.diff.gz
っていうことですね。意味がわかりました。
>> ところで、現状でも場合によってはメンテナ側が近い (回線の太い) 場所に
>> パッケージを置いて、 ftp メンテナがネットワーク経由でそれを取りに行く
>> ことが、すくなくとも JP では行なわれていたこともあるように思います。
これに関しては、最近行われた Debian JP 総会で、今後は認めないことに決
定してます。
今までは、Debian JP の master にしか Incoming がなく、しかも master
がネットワーク的に、条件の良い場所にあるわけではないので、極端に(ネッ
トワーク的に)遠いメンテナのことを考慮して、容認してきましたが、
debian.softagency.co.jp にも Incoming を作っていただいた(ありがとう、
村上さん)ことから、このどちらかのみに put することになりました。
理由は簡単
1) ftp メンテナの負荷軽減
2) master と softagency のどちらかを選択すれば、極端に遠い状況は起こ
らないと判断した。
です。
>> そうした場合に、例えば .dsc ファイルだけを専用の ML に送って、それを
>> ftp メンテナーが特定のスクリプトで受信すれば、自動的にネットワーク
>> 経由で取りに行ける仕組、とかいうのがもし実現できたら便利じゃないかな、
>> と思うのです。この場合、 .orig.tar.gz の構成物だけでなく、 .diff.gz
>> についても記述する必要が生じてきますけれども。
便利そうにも見えるし、不便そうにも見えます。が、少なくとも結局 ftp
メンテナの仕事を増やす結果になりそうだ、という気はします。
どっちにしろ、メンテナが ftp で Incoming に put する方式が、現状なに
か問題を起こしているとか、大きな負荷になっているという事実はないんで、
(確実に、なにかが改善される見込みがあるならいざ知らず)便利そうだという
利用だけで、方式を切り替えるのはどうかと思います。
まあ、この部分は佐野さんの意見の副次的な効果として考えられるというこ
とだと思うんですが、そうじゃないんでしょうか。少なくとも、ここの部分を
主要な効果だと考えてるなら、視点がずれてます。
>> > >> ソースパッケージをダウンロードしたければ、とりあえず
>> > >> .dsc と .diff.gz を入手する。 .dsc ファイルに書かれている
>> > >> .orig.tar.gz の構成物が、もし手元にあればそのまま使用できるし、
>> > >> もし無ければ、その上流コードがミラーされているところならどこでも、
>> > >> ( debian のミラーサイト以外からでも) 近いところから探して
>> > >> 入手すれば良い。
>> >
>> > こっちは、賛成します。要するに、FreeBSD の port とかに近い感覚ね。
>>
>> そうなんですが、けっして「 ports に近い」からそれがイイ、と考えて
>> いるわけではありません。 (この点は、むつみさんにも、また他の多くの
>> 方にもたぶん御理解頂けていると思いますが、念のため)
それは、わかってます。
>> ただ、もし枠組を変更することで、たとえば .orig.tar.gz の構成物を
>> それぞれ別に置くのと同様に、 NeoMagic パッチや C&T パッチなども
>> debianized patch と別にそれぞれ独立して置くことができて、しかも
>> それらから debianized source tree を作成する手順がどこかに記述
>> されており、 dpkg-source コマンドの使用によってコマンド一発で
>> これら複数の構成物から debianized source tree を作成できる仕組が
これ、前にもだれか言ってたような? (日本語パッチとかの存在を考えるなら、
複数パッチが利用できり枠組みがあった方が便利だとか)。
要するに
・ upstream original source tar ball
・ upstream pacthes
・ debian patch
のような形式にできればということですよね。この方式には個人的には賛成で
すが、そのためには、debian policy の改訂と dpkg 自身の大きな改造とが必
用になりますね。
＃なんか、ports と rpm から良いとこ取りした感じがするのは私だけで
＃しょうか?
--
From Nagoya
ishikawa@xxxxxxxxxxx, ishikawa@debian.or.jp
＊＊ 石川 睦％無意味な全文引用をする人は嫌い＠Japan Linux Users Group ＊＊
(Nagoya Linux Users Group)
My Debian-JP NEWS http://www.linux.or.jp/~ishikawa/linux/debian-jp/
X-TT 1.0 [Aoi MATSUBARA] http://www.linux.or.jp/~ishikawa/linux/X-TT/