[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:09184] Re: <bin package>_<version>_<arch>.deb ファイルの等価性
岡＠奈良先端です。
今考えるとまた寝れなくなってしまうんで、分かった点だけ。
"鵜飼"すなわちFumitoshi UKAIさんより:
> *_<arch>.changes は当然の事ながら <arch> 毎に別々で、さっき
> の怪しげな図を追ってみると、ここで枝分かれしている事が分か
> ります。例えば <bin package>_i386.deb に対して日本語の翻訳を
> 行って <bin package>_<version>_ja.trans (*1) なるファイルを
> 作成したとき、今迄のパッケージ関連ファイル全部と、このファイ
> ルと、自分自身を保証するファイルを作りたいのです(*2)。
鵜飼> 検討違いだったらごめんなさい。
鵜飼> とりあえず現在の仕組では ports build の時は changes には
鵜飼> deb しか Files: に入っていません。
鵜飼> これが 同じversion の source から作成されたことは
鵜飼> maintainerが(changesに署名することで)保証しているだけです。
鵜飼> なので翻訳も同じようにすればよいのではないかと思うのですが。
# たぶん樽石さんもこれと同じ事を言ってるんだと思いますんで、
ここで回答しておきますね。
PGP はこの際極論すると、重要ではなく、PGP 署名付いているこの
ファイル(orig.tar.gz では dsc, deb では changes) に入ってい
る md5sum の方が重要だと思うわけです(人の信頼とは別の話で、
途中で壊れていない事の保証)。
一つのファイルで自己保証する事も技術的には可能ですが、翻訳者
が手で書くファイルでそれを行うのはあんまりまともじゃないです
よね(gzip のように後で機械変換するっていう手もありますが)。
鵜飼> ただ翻訳の場合、original の version が同じでも翻訳の修正
鵜飼> の変更とかがありうるわけですよね。すると翻訳versionが
鵜飼> パッケージversionとは別に必要になるのかもしれません…
鵜飼> # あ、Packages とか Sources みたいに一つのファイルにして
鵜飼> # しまえば、毎回全部とってくるから翻訳versionがなくても
鵜飼> # どんどん更新はできるのかな?
そうですね、少なくとも形式的には翻訳 version なるもの、必要
ですね(作業をいい加減(=Slackware式)にしないためにも)。
メモ(あんまり真剣につっこまないでね...):
* オリジナルバージョンをtransファイルに付加する事に抵抗を
覚える。フォーマットとしては必要不可欠だが、翻訳作業とい
う観点からはミスが混入したり、Emacs のモードに依存してし
まうなどの(これはこれで便利なんですが、一般性を無視して
る)、見通しのよくない設計になってしまう。
# だから gettext の Emacs mode は、あんなに特殊な編集モー
ドになっている。
→ フォーマットと編集用のファイルは分離すべきか?
* 話が広がるのを恐れずに書くと、Packages や Sources ファイ
ルは、配布スタイルとしては要求を満たしているが、システム
内であのままの形で入るのは異常(apt はキャッシュを作るか
らいいけど dpkg はおかしい)。sendmail のメールスプールと
qmail 式のメールスプールを比較しても、ハードディスクが大
量にある現在の設計スタイルとしては qmail 式の方が優れて
いる。検索が速い点および堅牢性(一つが破損してもシステム
にクリティカルなダメージを与えない)。結果的にバックアッ
プを取る必要が低くなるので、かえってディスクを消費しない
かもしれない。
ここまで考えて、Translation ファイルの必要性を考えると、
パッケージツーリー上に置くのはいいが、取ってきて解体して
やりたいものだと思う。新案:
/var/lib/dpkg/
+ available/
| + admin/
| | + acct/
| | | + control
| | | + translation.ja
| | | + translation.de
| | ...
| + net/
| | + dnsutils/
| | | + control
| | | + diversion
| | | + translation.ja
| | | + translation.de
| ...
+ status/
| + admin/
| | + apt/
| | | + list # ← この二つ、まとめたいなぁ..
| | | + md5sums # ←
| | | + postinst # ← config db で置き換えたいなぁ...
| | | + postrm # ←
| | | + shlibs
| ...
+ cache/ # 速度向上が必要なら、ここまでやれ!!
| + 00/
| ...
+ bugs/
| + ?? # 機械修復可能なバグデータベース
さて、馬鹿も休み休みというからこの変^H辺で...。
> # おそらくは、もっとソースパッケージを体系化して(むろんビ
> ルド時の依存関係記述もその一つ)、低コストで情報を取り出せ
> るようにしておき、ソースパッケージレベルで翻訳するのが正
> 解だと思います。
鵜飼> ものによっては debian/control.in とかから build時に debian/control
鵜飼> を生成してたりするのでちょっとやっかいですね。
鵜飼> # まぁ Description の部分をいじってるパッケージはないと思いますが。
これについては(control.in 自体にも興味はありますが)、
"樽石"すなわちMasato Taruishiさんより:
樽石> 樽石です。
> # まぁ Description の部分をいじってるパッケージはないと思いますが。
樽石> kernel-image って違いましたっけ？
樽石> build 時に sed でメンテナとかいれてたと思う。
なんていう事例もあるし、よく考えるとソースパッケージは「フォー
マット」としての性格を満足していない事がようやく分かってきた
のでソースパッケージベースでの翻訳作業という話は無しにします。
# 現実性を無視すれば、「フォーマット化されたソースパッケー
ジ」を生成する「プリソースパッケージ」なるものを考える必
要がありそうです。それはいくら何でも やりすぎ ですね。
# 寝てからよく考えます...。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学