[Momonga-devel.ja:00677] Re: package(名)の整理について
- From: "Masahiro Takahata" <takahata@xxxxxxxxx>
- Date: Sat, 26 Oct 2002 06:35:50 +0900
たかはたです。
私の意味するところとしては、古いライブラリを整理することで
誰も使っていないようなアプリケーションをどんどんOBSOしていこう
という趣旨です。
----- Original Message -----
From: "KOMATSU Shinichiro" <koma2@xxxxxxxxxxxxxxxxxxxx>
To: <devel.ja@xxxxxxxxxxxxxxxxx>
Sent: Saturday, October 26, 2002 12:13 AM
Subject: [Momonga-devel.ja:00671] Re: package(名)の整理について
> 小松です。
>
> From: Masahiro Takahata <takahata@xxxxxxxxx>
> Subject: [Momonga-devel.ja:00668] package(名)の整理について
> Date: Fri, Oct 25, 2002 at 10:48:53PM JST
>
> > 第一段階として、バージョン違いな2パッケージを片方へ統一する
> > からはじめたいと思っています。
> >
> > パッケージ名 | momonga | redhat8
> > --------------|----------------------------|------------------
> > freetype | freetype-1.0,freetype2-2.0 | freetype-2.0
> > Xft | Xft2-2.0 | Xft-2.0
> > qt | qt2-2.3 qt-3.0.5 | qt2-2.3 qt-3.0.5
> > db | db1-1.85 db2-2.4.14 | db4-4.0.14
> > | db3-3.17 db4-4.0.14 |
>
> まず、freetype 関係については、
> freetype1 がないと VFlib2 に依存しているものが全滅します。
> もし全インストールしてあれば、rpm --test -e freetype とかすれば
> わかると思いますが、ほかにも多数のパッケージが
> freetype1(libttf.so.2) に依存しています。
>
> ではなぜ redhat では問題ないのかというと、
> 単に freetype の中に freetype1 と freetype2 の
> 両方が入っているから、というだけです。
freetypeの中に、freetype-1.0とfreetype-2.0両方入れないとすれば
freetype-2.0 , freetype1-1.0
という風に名前を変更すればよいかと思います。
これからの本流としてはfreetype-2.0系だと思いますし。
> また、db についてもほぼ同様で、
> compat-db というパッケージの中に
>
> db-2.7.7.tar.gz, db-3.1.17.tar.gz,
> db-3.2.9.tar.gz, db-3.3.11.tar.gz
>
> という 4つの version が入っています(db1 はないみたいですね)。
kikutaniさんのメールにも書いてありますが、少なくとも、
【db1】
OBSOることが出来そうですね。
【db2】
newpgのみ。php-dbaはdb[2-4]なのでなくても良い。
#newpgってgnupgと同じもののような気もしますが…
#tamoさん、これって何ですか?
【db3】
まだまだたくさんあります…。
という状況ですので、db1 db2がOBSOれるのではないでしょうか。
今、手元にあったredhat8なマシンがなくなってしまったので、
詳しくは見られませんが、compat-dbに依存してるライブラリ
をチェックしておかないとだめかもしれませんね。
Xft2はパッケージ名をXftにすべきでしょう。
qt2は依存しているパッケージがちょっとしたGUIな設定ツール
だったりする物もありますが、それが開発元でもメンテナンス
されていないものがあります。またこのGUIなツールがライブラリ
を使っているために、大事なものが作れなくなるのでは
元も子もない気もします。そういうツールについては、
依存してるパッケージの中で、使わないようにして行くということ
でよいかなとも思っています。
完全にqt2をOBSOるのではなく、依存しているパッケージを徐々に
減らしていって、最終的になくす方向でよいかと。
> あと、redhat のように、複数の version をまとめて
> 見掛け上 1つのパッケージにする、というのには賛成しかねます。
> どれか1つに修正が入れば全部を build し直すことになり、
> また、binary を落とす人も全部を落とし直すことになります。
> 皆が皆速いマシンと速い回線を持っているのであれば話は別ですが、
> 現実がそうでない以上やめるべきでしょう。
それほど、気にするほどのものでしょうか。
それに気を使うくらいならば、使わないパッケージをどんどんOBSOる方が
よっぽど建設的だと思いますが。
あと、一番悩ましい所がcompat-hogelibなものです。
実は商用ソフトではここが一番ネックだったりします。
redhat7.x時代にはredhat6.xで開発したバイナリを動かすために
必要とされていた、compat-glibcなど。
代表的なのはOracle8.1.7です。
これは、glibc2.1.3のライブラリの関数を使用しているために
compat-glibcで供給されるライブラリで使えるように
なっています。
compat-hogeがいやだーという話もわからなくはないですが、
以前のKondara-Asumiなどで商用対応ソフトが少なかったのは
こういう理由によるものだと思っています。
> > また、数字付パッケージ名というのもいかがかと思いますし…。
> 各 software ごとに対応する library が違うという現実がある以上、
> これは仕方がないでしょう。
仕方がないから、そこで何もしないのではなくて、momongaとして
どうしたらよいかという事を検討しているのですから。
必要ならば残し、必要でないならOBSOすればよいでしょう。
---
Masahiro Takahata
takahata@xxxxxxxxx
takahata@xxxxxxxxxxxxxxxxx