DragonFly - Packaging up the UserLand ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Dealing with Package Installation Applications are such a god-awful mess these days that it is hard to come up with a packaging and installation system that can achieve seamless installation and flawless operation. We have come to the conclusion that the crux of the problem is that even seemingly minor updates to third party libraries (that we have no control over) can screw up an already-installed application. A packaging system CAN walk the dependancy tree and upgrade everything that needs upgrading. The problem is that the packaging system might not actually have a new version of the package or packages that need to be upgraded due to some third party library being upgraded. シームレスなインストール作業と完璧な作業を得ることができるパッケージング・ インストールシステムを考え出すことが難しい現在、アプリケーションはとてもひ どく混乱しています。問題の核心は、表面上は外部ライブラリ(それは我々の管理 外)のマイナーアップデートであるように見えることですら、既にインストールさ れているアプリケーションを台無しにできることだという結論に私達は達しました。 パッケージングシステムが依存関係を管理し、アップグレードに必要な全てをアッ プグレードすることがあり得るのです。問題は幾つかのアップグレードされた外部 ライブラリのせいでアップグレードされる必要のあるパッケージやパッケージ群の 新しいバージョンを、パッケージングシステムが実際には持っているわけではない ということです。 We need to have the luxury and ability to upgrade only the particular package we want, without blowing up applications that depend on said package. This isn't to say that it is desirable. Instead we say that it is necessary because it allows us to do piecemeal upgrades (as well as piecemeal updates to the packaging system's database itself) without having to worry about blowing up other things in the process. Eventually we would synchronize everything up, but there could be periods of a few days to a few months where a few packages might not be, and certain very large packages could wind up depending on an old version of some library for a very long time. We need to be able to support that. We also need to be able to support versioned support/ configuration directories that might be hardwired by a port. Whenever such conflicts occur, the packaging system needs to version the supporting directories as well. If two incompatible versions of package X both need /usr/ local/etc/X we would wind up with /usr/local/etc/X:VERSION1 and /usr/local/etc /X:VERSION2. 私達は、望む特定のパッケージに依存した問題のあるアプリケーションを除いて、 同パッケージのみをアップグレードする能力と高級さを必要としています。これは 「それが望ましい」ということではありません。むしろ「それが必要である」とい うことです。それは(アップグレードという)手続きの中で問題を引き起こす他の物 事を心配することなしに、 (パッケージングシステムデータベース自身の段階的な 更新と同じように)断片的に(パッケージを)アップグレードすることを可能にする からです。最終的に私達は全てを同調させたアップグレードを行おうと思っていま すが、幾つかのパッケージがそうではなかった場合でさえ数日から数ヶ月の期間が かかりましたし、特定のとても大きなパッケージは、結局は長い間幾つかのライブ ラリの古いバージョンへ依存する結果になるかもしれません。私達はそれをサポー トできるようになることを望んでいます。また私たちは port によってハードワイ ヤードされても大丈夫な、バージョン分けされた対応と設定(を行える)ディレクト リをサポートできるようになることも必要だと考えています。このような競合が起 こった場合、パッケージングシステムはバージョン分けに対応したディレクトリを 同様に必要とします。例えば二つの X というパッケージの互換性のないバージョ ン双方が /usr/local/etc/X を要求した場合は、 /usr/local/etc/X:VERION1 と /usr/local/etc/X:VERSION2 という形で対処できると思います。 It is possible to accomplish this goal by explicitly versioning dependancies and tagging the package binary with an 'environment'... A filesystem overlay, you could call it, which applies to supporting directories like /usr/lib, /usr /local/lib, even /usr/local/etc, which makes only the particular version of the particular libraries and/or files the package needs visible to it. Everything else would be invisible to that package. By enforcing visibility you would know very quickly if you specified your package dependancies incorrectly, because your package would not be able to find incorrectly placed libraries or supporting files, because they were not made accessible when the package was installed. For example, if the package says a program depends on version 1.5 of the ncurses library, then version 1.5 is all that would be visible to the program (it would appear as just libncurses.* to the program). /usr/lib や /usr/local/lib のような、また /usr/local/etc でさえ対応ディレ クトリとして扱い、特定のライブラリの特定のバージョン、または/あるいはパッ ケージがそれが目に見えることを必要としたファイルのみ作る、ファイルシステム オーバーレイと呼ばれる'環境'と一体となった、はっきりとした依存性のバージョ ン管理とバイナリパッケージのタグ付けによって、この目標は成し遂げることが可 能です。その他のことはそのパッケージからは見えない状態になるでしょう。可視 性を強化することによって、特定のパッケージの依存性を不正確に指定した場合に とても素早く(それを)知ることができるでしょう。何故なら、パッケージがインス トールされた時にそれらが利用しやすい状態になっていないことによって、パッケ ージは誤って配置されたライブラリや対応したファイルを発見することができない からです。例えば、パッケージがこのプログラムは ncurses のバージョン 1.5 に 依存していると示している場合には、バージョン 1.5 がプログラムに対して可視 になる全てになります(それは丁度 libncurses.* という形で見えると思います)。 With such a system we would be able to install multiple versions of anything whether said entities supported fine-grained version control or not, and even if (in a normal sytem) there would be conflicts with other entities. The packaging system would be responsible for tagging the binaries and the operating system would be responsible for the visibility issues. The packaging system or possibly even just a cron job would be responsible for running through the system and locating all the 'cruft' that is removable after you've updated all the packages that used to depend on it. 上記のようなシステムの上では、きめ細かいバージョンコントロールがされたもの も、またそうでないものであろうとも、(普通のシステムの上では) 他のものと競 合を起こしてしまうものでさえ、あらゆるものの複数のバージョンをインストール できるようになります。そのパッケージングシステムはタグ付けされたバイナリに 対して責任を持ち、オペレーティングシステムは可視性の管理に責任を持つことに なります。そのパッケージングシステム、あるいはおそらく単なる cron ジョブが、 システムが走り続け、システムに依存して使われる全てのパッケージ群の更新完了 後に、削除できる全ての'問題'を見つけ出すことへの責任を持つことになるでしょ う。 Another real advantage of enforced visibility is that it provides us with proof-positive that a package does or does not need something. We would not have to rely on the packaging system to find out what the dependancies were; we could just look at the environment tagged to the binary! 他の可視性を強化することの現実的な利点は、パッケージが必要とする、あるいは 必要としない何かについて、私達に楽観性を与えてくれるということです。どんな 依存関係があるか調査するためにパッケージングシステムを頼る必要はありません; バイナリに対してタグ付けされた環境を見るだけでいいんですから ! (最後の段落は訳した自分でも意味不明。大体"タグ付けされたバイナリ"って何だ ? dfports の管理用データベースのことかしらん)