Ubuntu7.04への自動アップデートで思うこと。
途中に何回も「問い合わせダイアログ」が出てきて、さっぱり進まないのはなんとかならないのでしょうか。
……というか、せっかく「真っ当なパッケージ管理」が実装されているのですから、それを上手くいかしたアップデータを構成すると良いかも、と感じました。
たとえば、CD-Rの「テスト書き込み」のような手法をとって問いかけ文を全て探す……という方法をとると、事前に問いかけが全て判明するという点ではよいのですが、テスト部分だけでもとても時間がかかってしまいます。
あれは「バッファアンダーランに対する対策(burn-proofとか)がなかった時代の考え方」であって、「失敗すると取り返しが付かない」から生まれた考え方だったりするわけです。
……で、Ubuntuのアップデートは「失敗すると取り返しが付かない」のでしょうか。
実際のところは「パッケージ管理を使って部分的なロールバックをする」事自体は困難ではないのかもしれません。
しかも結局は途中で問いかけがあるたびに、大抵のユーザは「OK」や「続行」などのボタンを押しているはずです。
……とすると、こういうインストールプロセスもありなんじゃないかな……と。
- 「始めにアップデートに同意している」ということで、途中の問いかけは全て「同意」と見なして処理する。
- その際、「何を何に置換したのか」を、パッケージアップデータ側で記録しておく。
- アップデートが終わり、古いパッケージのクリーンアップを
行う前に行うダイアログの変わりに「パッケージの部分的ロールバックについての問い合わせダイアログ」を出す(古いパッケージを削除するか、あるいは部分的ロールバックをするかを選択するダイアログとする)。
「全体のアップデート処理時間がどれくらいかかるか」というところについてはかなり無頓着でも構わないのですが、「人が付いて(自働化できない)処理する時間」は徹底的に圧縮しないと、体感上の処理時間がとても長く感じられてしまい、システム管理上の理想である「なるべく手間がかからないこと」に近づけない状態になってしまいます。
こういう処理、現在のパッケージ管理システムでは「原理的に不可能」だったりするのでしょうか、あるいは「必要な処理を追加すれば可能」だったりするのでしょうか。
パッケージ管理システムの仕掛けをなんとなく推測する限りでは、こういった「後からなかったことにしてしまう」という方法を用いて、ユーザ問いかけの回数を一気に減らすことが可能ではないかと思います。
理想としてはWindowsのバージョンアップのように「ある程度前の方でまとめて問い合わせてくる」ことがよいのかもしれませんが、あれでもインストールプロセスごとに問いかけがあるなどして、ちょっと統一しきれていない気がします。
ましてやLinux系ディストリビューションの場合、そういった調整は原理的に不可能なわけで……とすると、結局は「最後に問いかけをまとめて行う」ほうが、よほど現実的なのではないかな……と、そう感じています。
……って、こう「書くだけ」で「行動しない」んじゃ、意味ないんだよなぁ＞自分orz。
いずれにせよ、いまのパッケージ管理は「自動化」を果たしていて、かつ「自働化」に耐えうるシステムであり、そして「自働化」をさらに推進するための「仕組み作り」がもっと進む必要があるように感じました。
今後の進化にはぜひとも期待したいところですね。
