[debian-devel:13706] towns & nec98 (Re: Re: hamm-jp removed and so on)

[Taketoshi Sano <kgh12351@xxxxxxxxxxx>]

佐野＠浜松です。

In <878zn8xd90.wl@xxxxxxxxxxxxxxx>,
 on "Thu, 15 Feb 2001 22:53:50 +0900",
 with "[debian-devel:13701] Re: hamm-jp removed and so on (Re:  debian-jp cleanup)",
  Fumitoshi UKAI <ukai@debian.or.jp> さん wrote:

> > >> いやそうではなくて、i386-{pc98|at|towns}をaptが自動選択
> > >> する、ということです。そのために、server側はx86共通package
> > >> と機種依存packageを、binary-うんぬんの部分で分けておく、と。

> いや 意味はわかります。$(ARCH) が i386-{pc98|at|towns} になるように
> しましょう という話ですよね?
> が、これに対応するにはかなりいろいろいじらないといけないような…。
> このためにいろいろ考えないといけないこともありますし、
> その労力にたいして見合うものが少なすぎるのでは?

とりあえず JP 独自のものを作ってもあまり意味が無いので
 Debian Project が採用している方法を参考にするのが良いと
思います。

>  * apt における $ARCH を i386 から i386-{pc98|at|towns} にしないといけない
>  * apt の $ARCH はdefaultは configure時の $host_cpu で決定しているが
>    pc98|at|towns 用をつくるのは無意味なので実行時に これを得る必要がある。
>    このような subarch を得るための一般的な方法はあるのか? 
>     (言うまでもなく i386に限定してはダメです)
>  * Debian における architecture の意味あいがかわってくる
>  * dpkg の修正などがいる? Architecture: はそのまま?
>    SubArchitecture: などを追加するのか?
>  * そもそも ここでいっている i386-at にだってマシンの構成によっては
>    使えないパッケージなどもいろいろあるわけで それらも区別するのか?
>    どこから subarch をわける基準にするのか?

 toshutils や tpctl などの「特定機種限定」のパッケージはありますね。

で、subarch が存在する arch として alpha や powerpc を参考にすると、
例えば powerpc には各機種用の fdisk として amiga-fdisk, atari-fdisk,
 mac-fdisk, pmac-fdisk などが binary-powerpc に混在しているようです。
 util-linux の説明にも fdisk や cfdisk が出てくるんですが、これらは
 powerpc でも含まれているのかな ?

 Alpha のほうは Jensen と Nautilus ? でインストーラのディスクは
異なるんですが、パッケージのほうは特に区別は無さそうですね。
カーネルの違いなのかな。

> むしろ それぞれのパッケージで実行時にどのプラットフォームか判断する
> (そのためにも同じ機能ならばできればマージしちゃう方がいいと思う)とか、
> preinst で assert してまずいプラットフォームにはインストール
> できないようにする 程度でいいと思うのですが?

私も可能であれば今後は binary-towns/binary-pc98 や binary-i386 に
統合していく方向で考えていったほうが、Debian へパッケージを持って
いく際にも都合が良いのではないかと思います。とりあえず potato-jp と
おそらくは woody-jp あたりまでは binary-{towns,pc98} を継続しても
いいかとも思ってますが。

 disks-towns, disks-pc98 のほうはまだしばらく別にしたほうがいいのかな。
このへんも統合するとなると、けっこう作業が必要な気がする。

Joey Hess の debian-installer が一般にリリースされるようになったら
 disks-i386 以下の sub arch として統合していく方向で考えるのがいいかも。

> # この場合、そのパッケージが適用される範囲でどのプラットフォームかを
> # 判別するだけでよく一般的な判別方法を決める必要はないので。

「共通では使えないパッケージ」というのはそれほど多くないということ
なので、メタパッケージとか task とかで適当に依存関係設定してしまう
というのもありなのかな、と。

「towns にはこのメタパッケージ必須」とインストールマニュアルなどで
説明しておいて、そこに

   「towns にはインストールしていけないパッケージ」を排他で
   「towns にはインストール必須なパッケージ」を依存で
   「towns にはインストールしておくと便利なパッケージ」を推奨で、

とか設定する、というのはいかが ?

あ、PC98 用には上記を s/towns/pc98/g して同様に適用してみてください。

 (pc98 がいいのか、nec98 がいいのか、どっちなんでしょう ?)

--
     ＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
    <kgh12351@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)