アカウント名:
パスワード:
deb パッケージ形式は、現在でも進化を続けています。それは裏を返せばそれだけ進化の余地があるということでもあります。
たとえば、Build-Depends フィールドがつい最近追加されました。これは、コンパイル時に必要なパッケージの一覧を書くものです。Description フィールドの翻訳プロジェクトがつい最近始まりましたが、ad-hoc な方法でとりあえず使えるという状態なので、これをいかに正式に dpkg に実装するか、ということがそのうち議論されると思います。また、バイナリパッケージへの署名も、現在の deb フォーマットが欠けている項目です。
構築過程がへんだ、という話は今まで聞いたことがなかったですが、たしかにそのとおりだと思います。Makefile ベースというところは変えなくても、その内容は自由なので、debhelper に代わるユーティリティを作れば、従来との互換性を保ったままきれいな実装も理論的には可能です。問題は、だれが「やろう」と言い出すか、ということです。
アップストリームレベルのパッチをあてたい時、というのも、deb フォーマットのなやみの種です。ソースパッケージの中に .tar.gz を入れておいて、構築時に展開してパッチをあてて、という方法を取っているパッケージや、ぜんぶアップストリームレベルに押し付けたり Debian パッチに押し付けたり、と、パッケージメンテナによってばらばらです。ばらばらなのは、統一ガイドラインがないことはもとより、それぞれ一長一短があるからです。ちなみに、一番最初の形式の欠点は、ソースに手を加える (つまり、Debian パッチの部分を編集する) のが困難になることです。
パッケージのインストール時・削除時に使われるコンフィグレーションスクリプトの複雑さも、問題だと思っています。従来からどんどん拡張されてきたっぽい複雑さを抱えています。debconf がさらにその複雑さに輪をかけているような気もするんですが、どこまでが必要な複雑さで、どこまでが不要な複雑さなのか、ぼく自身見極めができていません。
だれか、改良する人、いませんか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
deb パッケージ形式 (スコア:2, 参考になる)
deb パッケージ形式は、現在でも進化を続けています。それは裏を返せばそれだけ進化の余地があるということでもあります。
たとえば、Build-Depends フィールドがつい最近追加されました。これは、コンパイル時に必要なパッケージの一覧を書くものです。Description フィールドの翻訳プロジェクトがつい最近始まりましたが、ad-hoc な方法でとりあえず使えるという状態なので、これをいかに正式に dpkg に実装するか、ということがそのうち議論されると思います。また、バイナリパッケージへの署名も、現在の deb フォーマットが欠けている項目です。
構築過程がへんだ、という話は今まで聞いたことがなかったですが、たしかにそのとおりだと思います。Makefile ベースというところは変えなくても、その内容は自由なので、debhelper に代わるユーティリティを作れば、従来との互換性を保ったままきれいな実装も理論的には可能です。問題は、だれが「やろう」と言い出すか、ということです。
アップストリームレベルのパッチをあてたい時、というのも、deb フォーマットのなやみの種です。ソースパッケージの中に .tar.gz を入れておいて、構築時に展開してパッチをあてて、という方法を取っているパッケージや、ぜんぶアップストリームレベルに押し付けたり Debian パッチに押し付けたり、と、パッケージメンテナによってばらばらです。ばらばらなのは、統一ガイドラインがないことはもとより、それぞれ一長一短があるからです。ちなみに、一番最初の形式の欠点は、ソースに手を加える (つまり、Debian パッチの部分を編集する) のが困難になることです。
パッケージのインストール時・削除時に使われるコンフィグレーションスクリプトの複雑さも、問題だと思っています。従来からどんどん拡張されてきたっぽい複雑さを抱えています。debconf がさらにその複雑さに輪をかけているような気もするんですが、どこまでが必要な複雑さで、どこまでが不要な複雑さなのか、ぼく自身見極めができていません。
だれか、改良する人、いませんか?