[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:08289] Re: slink release schedule
岡野です。
In message "[debian-users:08287] Re: slink release schedule"
on 98/09/09, Hiroshi KISE <kise@xxxxxxxxxxxx> writes:
> 自分で書いておいてなんですが、古いバージョンのやつを確保してお
> く理由ってなんでしたっけ? 不具合があったときにソースを調べて手
> を入れるためだったかな…。
導入した環境を再現しなければならないケースってあると思います。導
入後しばらくしてから不具合のクレームがあったときとか。
ユーザが導入時のままで使っているとも限らないし、問題点の洗い出し
をするためには元のバージョンが必要になるのではないでしょうか。
> 安定しているシステムであれば、わざわざ最新のstableをおっかけな
> くてもよいのではないでしょうか。
これは同感です。ただ、Kaneko さんのおっしゃる商用アプリケーショ
ンを提供する立場では最新安定版を追いかけざるを得ないのも納得でき
ます。MS な OS でも Apple のでも新版が出るとフリーウェアのベンダ
さんたちも個人でやってても一所懸命になって対応しようとしますよね。
> セキュリティとかバグの修正のときにだけ、対応するパッケージを入
> れ替えればよいように思えます。
これが、結構難しいという気はします。Update・Bug レポートをずっと
追いかけて、要不要を判定しつづけるのですから、最新版を追っかける
のと労力は変わらないどころか、むしろ大変なのではないでしょうか。
思ったんですけど。セキュリティホールやバグ潰しのための Update と
新機能導入や新パッケージ追加のための Update が別になっていたら少
しは楽になったりしないでしょうか。
全部が全部 slink(-jp) じゃなくて、slink-update と slink-project
が別々に走って、リリース時に統合されるとか。
基本的に -update の方を取り入れていれば安全かつ安定して運用でき
ますよみたいな。無理でしょうか。冷静に考えると線引きをどうするの
かとかパッケージを出す方の労力が2倍になるという気もしますが。
> (dselectだと全部変更しようとするので、dpkgで1つ1つ入れてやらな
> ければいけませんが)
select menu で一個一個チェックしてホールドしていくのと変わらない
ような。
--
岡野大 (oKaHo, gau) mail : gau@xxxxxx