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

[debian-devel:14801] Re: ITP: samba-ja 2.2.2ja1.0beta1



佐野@浜松です。

In <20020113104125.5466E53814@xxxxxxxxxxxxxxxxxxxxxx>,
  on "Sun, 13 Jan 2002 19:41:26 +0900',
   with "[debian-devel:14798] Re: ITP: samba-ja 2.2.2ja1.0beta1",
 Kenshi Muto <kmuto@xxxxxxxxxxxxxxx> さん wrote:

> > > >   日本Sambaユーザ会のリクエストに応えて、日本語パッチの当たった Samba のパ
> > > > ッケージ一式をITPします。
> > > ・manpages-ja と競合
> > 
> >   manpages-ja から該当ファイルを省くのが適当と考えます。
> 
> ローカルなパッケージが、Debianのofficialパッケージに対して「ファイルが
> 衝突するからそっちが消せ」というのも変な話ですね。
> 
> samba-jpをofficialにITP→official化→samba-jpのmanのほうが新しいという
> 理由でmanpages-jaから削除するようBTS
> 
> が正規の手続きでは。

んん、まぁローカル / オフィシャルの話はそれとして、
筋から言えば manpages-ja に含まれる manual page というのは
それぞれのパッケージに日本語版のマニュアルが含まれるまでの
つなぎというか暫定対処のようなものかなとか思うのですが、
どうなんでしょう ?

で、とりあえず JP パッケージの samba-ja に日本語版の
 manual page が含まれているとして、それを理由に
(-ja でない) samba パッケージにそれらの日本語訳
 manual page が含まれていない段階で manpages-ja から
 smbumount や smbclient などの日本語訳 manual page を
消してしまうと、従来からの samba パッケージを利用している
人は、ある日突然日本語訳された manual page が消えてしまう
ことになるわけで、あまり望ましいことではないような気が。

だから、manpages-ja から該当する manual page を消すのは
(samba-ja が JP local であるか official であるかに
かかわらず) samba パッケージにそれらのページが含まれた
後にすべき、と思います。

あと、わりと最近にも Joey Hess が slrn-ja と cvsbook-ja に
関してブツブツ文句を言っていたのを debian-devel@Org で
見かけましたが (cvsbook-ja に関しては個人的には彼の意見に
異議があるんだけど、時間が無いので議論はしてません) 
今の時点で新しく -ja なパッケージを持っていこうとしても
すんなり受け入れられるとは思えないです。

もし Debian にそのまま持っていくなら、最低でも Debian の
samba パッケージのメンテナーに連絡を取って、独自パッケージの
必要性について了解してもらわないと、後で devel@Org ML あたりで
問題になる可能性が非常に高いと思われます。

一方、mhatta さんが書かれたように upstream/Debian レベルで
統合 (マージ) していくことについてですが、これも単純には
いかない場合もあります。例えば potato の時には gs-ja の
パッチを gs に統合しろという指示が Debian Project の主要
メンバー (Vincent とか Wichert とか) から出されて、それに
従うかたちで VFlib パッチを Debian official に入れたわけ
ですが、それについて例えば Debian-KR のメンテナー (だけ
とは限りませんが) からは後で愚痴やら不満やらが出たりも
しているという状況があったりします。

samba-ja が samba と異なる部分の詳細について私は知りませんが、
もしそれが ja のサポートを向上させるために例えば ko や zh の
利用者に犠牲を強いるようなものがあるとしたら、Debian レベルでの
統合についても慎重に検討する必要があるかもしれません。

私自身は、当時 Debian Project の中で (debian-devel ML での
議論によって) 決められた「とりあえず出してから考えるべし」と
いう方針に従って、どんどん出していくほうが良いという考えですが。

もし他の言語での利用に支障があるようなら、どういう支障があるのか、
どうすれば解決できるのか、という点についてきちんとその言語の
利用者からフィードバックをもらわなければ、解決できませんから。

今までいろいろなソフトウェアの日本語対応が進まなかったのは、
そのへんで妙に遠慮してしまって、「きちんとした国際化じゃないから
出さないほうがいい」とか「きれいなパッチじゃないから国内に
限定しよう」と萎縮して自主規制してしまったせいもあるのではと
思っています。

すくなくとも Debian Project の内部では
「そういう遠慮は捨てて、とりあえずどんどん出すべき」
というのが現在の方針のはずなので、個人的には samba に
ついても -ja な部分のパッチを BTS に送っておくこと
だけでもやっておいたほうがいいんじゃないかと思います。

が、これはあくまで私自身の考えですし、今のところ samba の
メンテナーとの交渉を代行するような時間も取れそうにないので
実際にどうするかは吉山さんにおまかせします。

とりあえず現状どおり JP パッケージとして日本語圏内限定で
配布するということでも、私自身は特に異議はないです。

 (一応は samba-jp プロジェクトのほうで upstream への
  統合を目指すということになっているはずだろうし)

ただ、samba パッケージを使っている人も、samba-ja パッケージに
乗り換える人も、どちらも「日本語マニュアルページ」を利用できる
ようにはしてもらいたいと思います。

なので、この「manual page の重複」という点に関してだけいえば

> samba-jpをofficialにITP→official化→samba-jpのmanのほうが新しいという
> 理由でmanpages-jaから削除するようBTS

という手順よりも

 1) samba パッケージに manpages-ja の samba 関連日本語マニュアルを
    含めてもらうよう BTS

 2) 当面の暫定措置として samba-ja 用の日本語マニュアルも
    manpages-ja の中に含めてもらう、あるいは samba-ja で
    divert を利用して manpages-ja の該当するファイルを
    退避させる (この場合パッケージの remove 時に divert も
    remove することを忘れないように) 

 3) samba パッケージに日本語マニュアルが含まれたら manpages-ja から
    該当するファイルを削除してもらうよう BTS

 4) samba-ja パッケージに該当するファイルを追加、あるいは
    divert 処理を廃止

といった手順のほうがふさわしいのではないかと思います。

そういえば devel-changes にむつみさんが書いてたけど、
 samba-doc-ja って同名のパッケージが sid にあるそうですね。
バージョンは古いみたいだけど。これはどうすればいいのかな ?

-- 
 # (わたしのおうちは浜松市、アカウミガメのふるさとの街)
   <kgh12351@xxxxxxxxxxx> : Taketoshi Sano (佐野 武俊)