アカウント名:
パスワード:
お客さんじゃないのにapt-getでアップデートできるのがそんなに重要なの?って聞いてるだけなんですが。
「お客さん」ではないと自負している人がapt-getを振りかざす不思議さ。
まさに「怒らせようとしてる書き込み」の代表例ですね。
おお、釣れた釣れた。
potato が古すぎることには同意。日常では使えん。 しかし woody はもう十分に安定性を持っていると思うが?
sid はさすがに問題有り。今も locales と libc6 のバージョンが合わなくて potato/woody からは upgrade できなくなってる。
つまり、以下のようなことです。
libc6 パッケージと locales パッケージ (および libc6-dev パッケージなど) は同一のソース (glibc) から同時にコンパイルされます。ここで、libc6 パッケージは各アーキテクチャごとに別パッケージですが、locales パッケージはアーキテクチャ依存なファイルを含まないので全アーキテクチャで同一のパッケージを用いるということに注意してください。 glibc のメンテナの Ben Collins さんは sparc を使っているので、sparc 用の libc6 パッケージと全アーキテクチャ用の locales パッケージを作ることになります。
これが Debian アーカイブに登録された時点で、i386 ユーザから見ると、古いバージョンの libc6 と新しいバージョンの locales があるように見えます。libc6 と locales はバージョンが一致している必要があるので、locales は「依存関係を満たせないためにインストール不可能なパッケージ」とみなされてしまいます。
数日中に、buildd [debian.org] が i386 用のパッケージを自動的にコンパイルすると、問題が解消します。(ただし、glibc のソースにバグがあって、sparc ではコンパイルできるけど i386 ではコンパイルできないなどの問題が発生すると、この問題は長引く可能性もあります)。
リリース済みのRHなんかよりはずっと安定しているというのが僕の印象です。
テスト版には、みんなが使うような人気パッケージをインストールしたらシステムが壊れたとかいうような重大なバグは、たぶんないでしょう (そういうバグは 10 日以内に報告されるはずだから)。ただし、「10 日」のラインを 5 日または 2 日にすることが、パッケージメンテナの独断でおこなうことが可能です。
むー。今まではボランティアベースのコミューンを信用してサーバに使ってたけど、そのコミューンの雰囲気が嫌になったからやめるわけですね。まぁ、サーバ関係でサポート必須でしたらやはりそれなりのディストリビューションを使うべきかと。
ただ、ここでのやり取りで「嘘を書くな!」さんがDebianから離れたとしても仕方ないと思いますが、それは/.-jであなたが嫌な気分を味わったからであって、Debianやユーザコミューンの雰囲気に問題があるわけではないと思いますが。
「嘘を書くな!」を書いた者だが、 嘘を書くと「参考になる」で、真実を書くと「荒し」なのか。 しょせんはボランティアベースでは限界があるのかなぁ。
今回は、多少の期間はメンテする、ということのようですが、どうなることやら。
安定版(potato)がやたら古くて、テスト版(woody)や不安定版(sid)を使わないといけない。 企業で採用しようと思っても、まさかテスト版や不安定版を使用するわけにはいきませんしね。
企業で採用しようと思っても、まさかテスト版や不安定版を使用するわけにはいきませんしね。
横からコメントですが、potatoに限って言うと、Xが3.3.6なので今時のGeforce系ビデオカードが間違いなく全滅なんですね。
で、自分の会社で使うのならX ver.4系の非公式.debをインストールできますが、他社に使わせるとなると、細かいインストールマニュアルを書かないといけません。これはいやらしい。
でも、woodyにしたってGeForce4をサポートできない(X4.2でもサポートしていないからwoodyのせいではない)という痛い事実があります。相手様にビデオカード選択の注文を付けるのを忘れていて泣きました。
gcc, gtk+, gtkmmを使っています。ソースコードは非公開なので、ライセンスに非常に気を使いますね。gettextを使いたいのですが、GPLなので使えません。代わりとなるコードを書いてたりします。
ツールの完成度はまだまだなので、それを理解して下さるお客様のみに提供しています。顧客数は一桁ですので、あまり参考にはならないですね。それでもdebian普及に貢献したいのでディストリビューションをdebianに指定しているのですが、、、先のような問題に当たってしまうのです。
正論で喧嘩売られているときには正論で答えるのがスジだと思いますよ?
そのへん歩ってて、知らない人からいきなり喧嘩を売られると僕はイヤっす。喧嘩を売るんでなしに、議論をふっかけてくれ。応じるから。
ふーん。お子様なんですね。
負けを認めたわけですね。
そもそもプログラムの新しいバージョンが出るということ自体、不具合が直されたと考えてはいけないのでしょうか?
たぶん Apache だけだとそれほど大変ではなくて (パッケージによると、設定ファイル移行を補助するスクリプトがついてきたりします)、ディストリビューションのバージョンアップの際にはたくさんのソフトウェアがバージョンアップするので、それらのうち設定ファイル等の移行作業が必要なものを洗い出し、洗い出した全てについて以降作業を行う、というところが大変だと思います。
こういう場合の対処方法としては、少しずつバージョンアップする、という方法があります。apt-get -su upgrade でバージョンアップが必要なパッケージの一覧 (ディストリビューションのバージョンアップに際しては、たぶん全部になります) を表示し、そのなかから「今日はこれ、明日はこれ」というふうに徐々にバージョンアップしていくのです。依存関係のため、多数のパッケージが一気にバージョンアップしてしまうこともありますが、作業の分散にはちょっとは役立ちます。
ちなみに、こういう方法をとったとき、いつの時点をもってシステムが新バージョンに移行したとみなすか、というのは決まっていません。/etc/debian_version というファイルが base-files パッケージに入っていますが、これは単に数字を記憶しているだけのファイルですし。(気分的には、libc のバージョンアップをもってシステムのバージョンが上がったとみなすのがよさげ)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
ホントに (スコア:2, 参考になる)
まだっすか?
愛用のKondaraがこんなことになった [srad.jp]んで
以前使っていたDebianに戻ろうかなーと思っているんですが
このリリースの遅さはやっぱ気になります。
これだけリリースが遅いと、人に勧めにくいし。
どんなに
激しく同意!! (スコア:2, すばらしい洞察)
そんな状況に「俺が使えてるからいいんだYO!」と開き直るようでは、Debian使いも底が浅い人たちばっかりですね:-)
スキルのある人にはそりゃ何でも使えるでしょうが、初心者に薦めよう!と思ったとき、やたら古い安定版をどうにかこうにかしてパッチ当てして使ってるようなDebianはとても薦められません。
企業で採用しようと思っても、まさかテスト版や不安定版を使用するわけにはいきませんしね。
Re:激しく同意!! (スコア:3, すばらしい洞察)
それにボランティアベースでメンテナンスされているものに「リリースが遅すぎる!」と声高に言うのはどうかと思います。
そういう部分で問題になる用途に使うのであれば、素直に有償サポートを受けられるものを使う方がよろしいかと思います。
Re:激しく同意!! (スコア:1)
BSD系の文化は由緒正しいUNIX文化だからこういう反応なのかもしれませんね。ユーザーを「お客さん」にしてるRedHat系の文化(Linux文化とは言いません)との違いかもと思いました。
用途が業務用か個人用かに関わらず、必要なものは自分でいれて自分で管理するのがUNIXの世界だと教えられてきましたが、昨今は人に管理してもらいたい人が多いんでしょうかね。
匿名の臆病者さんたちは、あくまで「お客さん」でいたいんでしょうね。
Re:激しく同意!! (スコア:1)
aptとdpkgがもらって来るだけのツールだとでも?
一例としてあげますが、たとえばapt-get sourceなんて何のためにあると思ってるんですか?
Re:激しく同意!! (スコア:1)
そうは聞こえませんね。
誰がお客さんでないと自負し、誰がapt-getを振りかざしたのか不明なままでしょ? これが私に向けて言われた言葉なのであれば、今回の議論では私は何も自分がお客さん状態ではないと言ってもいませんし、apt-getを振りかざしてもいません。
言ってもいないのに私を「お客さんでないと自負」し「apt-getを振りかざす」人間にしたがる。もはや陰謀ですね。
もし私以外の人間に向けて言われた言葉であれば、それはdebianユーザ全体へでしょう。しかし誰も自負も振りかざしもしてない。つまりはdebianユーザの誰かを怒らせようとしてるわけです。
なので、聞いてるだけ、というのはありえませんね。
そしてお客さん状態でなくてもdeb化し、aptで更新できることのメリットはたくさんあります。一人でこの世の全てのソフトウェア群を管理できるなら話は別ですが。
Re:激しく同意!! (スコア:1)
「apt-getは一発簡単」は極論すぎます(^^;;それ自体は簡単だと思いますけど、Updateされる内容を事前に確認して必要かどうかを見極めないといけないのには変わりない無いわけで、他の方法よりも「少しは楽かも?」程度の事でしか無いと私は思っています。ここら辺は単に好みの問題じゃ無いでしょうか?
Re:激しく同意!! (スコア:1)
訂正ー
-論理が破綻してると言うわりにどこが破綻してるのか説明もなく、
-「明白だよね」で終らせてる。
-これはもう「明白に見せかける」ための陰謀ですね(わら
+論理が破綻してると言うわりにどこが破綻してるのか説明もなく、
+「明白じゃないよね」で終らせてる。
+これはもう「明白じゃなく見せかける」ための陰謀ですね(わら
Re:激しく同意!! (スコア:1)
根拠 などと書いている事。何か不十分ですかね。
Re:激しく同意!! (スコア:1, 参考になる)
potato が古すぎることには同意。日常では使えん。 しかし woody はもう十分に安定性を持っていると思うが?
sid はさすがに問題有り。今も locales と libc6 のバージョンが合わなくて potato/woody からは upgrade できなくなってる。
localesパッケージ問題 (スコア:3, 参考になる)
つまり、以下のようなことです。
libc6 パッケージと locales パッケージ (および libc6-dev パッケージなど) は同一のソース (glibc) から同時にコンパイルされます。ここで、libc6 パッケージは各アーキテクチャごとに別パッケージですが、locales パッケージはアーキテクチャ依存なファイルを含まないので全アーキテクチャで同一のパッケージを用いるということに注意してください。 glibc のメンテナの Ben Collins さんは sparc を使っているので、sparc 用の libc6 パッケージと全アーキテクチャ用の locales パッケージを作ることになります。
これが Debian アーカイブに登録された時点で、i386 ユーザから見ると、古いバージョンの libc6 と新しいバージョンの locales があるように見えます。libc6 と locales はバージョンが一致している必要があるので、locales は「依存関係を満たせないためにインストール不可能なパッケージ」とみなされてしまいます。
数日中に、buildd [debian.org] が i386 用のパッケージを自動的にコンパイルすると、問題が解消します。(ただし、glibc のソースにバグがあって、sparc ではコンパイルできるけど i386 ではコンパイルできないなどの問題が発生すると、この問題は長引く可能性もあります)。
Re:激しく同意!! (スコア:0)
Debianに詳しい人なら理由を知ってるのかもしれませんが、縁が無い人からは<B>古いディストリビュ
Re:激しく同意!! (スコア:1)
Debianのリリースの基準は他のディストリビューションより相当厳しいので、今のwoodyでも十分実用に耐えると思います。リリース済みのRHなんかよりはずっと安定しているというのが僕の印象です。 リリースサイクルはやっぱり遅すぎると思いますけどね。
Re:激しく同意!! (スコア:0)
Re:激しく同意!! (スコア:1)
Re:激しく同意!! (スコア:0, 参考になる)
あんまりメンテされないですよね。いまだと、6系とか。
それに、私や、私のまわりでの話ですが、RH6系から7系に移行
したとき、7.1 ではなく 7.2 になってから選んでいる人が多
いです。RHは.1は不安定に違いないってゆー、一種のおまじない
に近いですが^^;
Debian はこういう細かいバグフィックスは、基本的に
どのリリース(安定版、テスト版、開発版)にも継続して
行っています。特にセキュリティバグフィックスは、非常に
配布が早いのは皆さんご存知のとおりだと思います。
そういう古いディストリビューションのメンテナンス
Re:激しく同意!! (スコア:0)
まずいです。営利目的なので仕方ない一面があるが、RHは安定
したバージョンが出揃うの待てず、ただ収益のためにバージョン
アップを繰り返している気がする。
MySQLの開発陣も、開
テスト版の位置付け (スコア:4, 参考になる)
テスト版には、みんなが使うような人気パッケージをインストールしたらシステムが壊れたとかいうような重大なバグは、たぶんないでしょう (そういうバグは 10 日以内に報告されるはずだから)。ただし、「10 日」のラインを 5 日または 2 日にすることが、パッケージメンテナの独断でおこなうことが可能です。
Re:激しく同意!! (スコア:3, 参考になる)
それに比べて Red Hat は 1 世代前のメジャーバージョンまで、 きっちりサポートを継続してくれる。 現状では 6.2, 7, 7.1, 7.2, 7.3 と 5 世代も面倒見てくれてる。 6.2 用のアップデートが 6.0, 6.1 にも当たるので実質 7 世代。
Red Hat のリリースはほぼ半年おきで、今使っている版が いつまでサポートされているか明らかなので安心して使える。 それに比べて Debian はリリース時期が不透明なので アップデート計画が建てづらい。
Re:激しく同意!! (スコア:1)
何か勘違いしていませんか?RedHatは「仕事として」サポートしてるんですよね?
Re:激しく同意!! (スコア:0)
>何か勘違いしていませんか?RedHatは「仕事として」サポートしてるんですよね?
そういう問題ではないのでは?
単純に嘘を書くなってことでしょ?
それに、最初にRHLとの比較を持ち出したのは#125370 [srad.jp]です。
Re:激しく同意!! (スコア:1)
>単純に嘘を書くなってことでしょ?
>それに、最初にRHLとの比較を持ち出したのは#125370 [slashdot.jp]です。
#125370 [slashdot.jp]の方も含め、
「商用サポートがある」物と「商用サポートが無い」ものを比較する事には余り意味がないかと思います。
Debian互換の「商用サポートのある」ものと比較するのには意味があると思いますけどね。
Re:激しく同意!! (スコア:0)
だれもそのことに反対してないよ。
Re:激しく同意!! (スコア:1, すばらしい洞察)
RHだと、apt並みの整合性の取れたシステム全体の
アップグレードって事実上不可能だからサポートせざるを
得ないんじゃないかな?
額面上のリリースを頻繁にすればいいって問題じゃないでしょう。
以下、俺の認識
RHx.0 -> unstable
RHx.1 -> testing
RHx.2以降 -> stable
Re:激しく同意!! (スコア:1, 興味深い)
それが一番分かりやすいですね。
redhat は7.2が出るとそれ買ってきていれる、って感じ
だからリリースを待つ。
debian は、リリースが流れたときには、ほとんどの
ユーザはaptでそれともうまったく同じ構成のものを手元に
持って使っていて、あーこれに正式にバージョン振られたのね、
っていう感じですね
正式版は、パッケージ的な要素を持ってるから、しょうがないから
リリース番号を付けていますが、ちゃんと面倒見てる人なら
ほとんど毎日アップグレードかけてるんじゃないですかね^^;
私はsidを使っていますが、aptするときがバージョンアップ
だとすると、一日2回くらいの頻度であげてますよ
Re:激しく同意!! (スコア:0)
>>>そういう問題ではないのでは?
>>>単純に嘘を書くなってことでしょ?
Re:激しく同意!! (スコア:1, 参考になる)
Re:激しく同意!! (スコア:1)
正直、7つものリリースをメンテするリソースがあるなら、もうちょっと別の方向に使っていいと思う。
debianはリリース時期が不透明と言うが、リリースされてから対応したって遅くは無かろう。
私は新参者なのでpotato以降しか知らないが、匿名の臆病者氏が言うには旧stableのバージョンも半年はメンテされるのであろう?
半年もあれば計画を立てて実行するのに十分な期間であると思うが?
実行するにしたってdist-upgradeするだけで、再起動も要らないんだし。サービスが止まる時間は皆無に等しいだろう。
それにリリースまでのテスト期間は圧倒的にdebianのほうが充実してると思うが?
Re:Debian はもうおしまいだな (スコア:1)
むー。今まではボランティアベースのコミューンを信用してサーバに使ってたけど、そのコミューンの雰囲気が嫌になったからやめるわけですね。まぁ、サーバ関係でサポート必須でしたらやはりそれなりのディストリビューションを使うべきかと。
ただ、ここでのやり取りで「嘘を書くな!」さんがDebianから離れたとしても仕方ないと思いますが、それは/.-jであなたが嫌な気分を味わったからであって、Debianやユーザコミューンの雰囲気に問題があるわけではないと思いますが。
Re:Debian はもうおしまいだな (スコア:1)
この現象は、別にDebianのコミュニティの現状そのものを表している訳ではないと思いますよ。
どのコミュニティでも盲目的に応援している人はいるものです。
積極的に活動している人は、おそらく、一部の子供じみた反応をしている人とは
違った視点で批判を見ていると思います。
実際、そういう反応をしている方もいますしね。
Re:激しく同意!! (スコア:1)
たぶん難しいのではないかと思います。
試したことはありませんが。
Re:激しく同意!! (スコア:1)
今回は、多少の期間はメンテする、ということのようですが、どうなることやら。
Re:激しく同意!! (スコア:1, すばらしい洞察)
アップデートするのは、まず無理/大変に難しい/リスクが高い/
保証されない(お好きなものをご選択ください)。長く使いつづけ
ようとした場合、
・最初入れたバージョンが更新される限り追従して後は放置
・上記の更新終了後、その時点での最新版を1から入れなおす
のどちらかを選択することになる。
Debianの場合、例えば現状のようにトラブルがある時期はあったと
しても、既にコメントされているように、それはやがて修正されて、
コマンド一発でアップデートできるようになるので、ベースに
関わらず、その時点での最新版と同等の内容にする、という
選択肢が増える。
リリースというものについての認識の違いを、相手方の「嘘」として
片付ける人には、リリースがいつまでたっても出ないというのも
そりゃそうでしょうなぁ、としかいえないわけで。
とはいっても、アップデートの特徴やリリースの方針なんてのも、
それぞれの個性なわけで、優劣の問題じゃあない。どちらにしても
需要にこたえて「そう」しているわけだからね。
だから、要件と照らし合わせて適切な選択をすればいいんじゃないの?
特徴やら条件を考えもせずになんでも全てDebianだ、RedHatだ、と
(商用/非商用の区別もせずに)言い合ってても仕方ないでしょ。
既存のコメントからの類推だけど、
・金銭を伴うサポートを受けねばならない(そしてRHの特定
バージョン向けのサポートしかないであろう)商用アプリ
ケーションを利用している
・担当者が一掲示板を眺めて受けた印象と気分でシステムを
入れ替えることが可能
であれば、言うまでもなく最適解はRHだよ。deb厨の主張に耳を貸す
必要は全くないでしょ。
Re:激しく同意!! (スコア:1)
RPM4は下位互換でRPM3もサポート(?)しているみたいなので、
RPMから先にアップデートすれば、技術的にはできそうですね。
各パッケージの問題は分かりませんが。
ポインタ付けてよ。 (スコア:1)
「『嘘を書くな!』を書いたものだが」
とだけ言われても、
どこで書いたのか探すだけでもおおごとなんですが、、、
Anonymous Coward で好き勝手書いても
別にかまやぁしませんので
せめてポインタ付けていただけませんか?
uxi
ユーザーは自由 (スコア:2, すばらしい洞察)
使いたくないユーザーは使わなければ良い。
ユーザーには選択の自由があるのだから。
しかし、
リリースが遅いからとか
サポートが悪いからと言って
Debian がだめだと言うのなら
Debian 選んだ事そのものが
そもそもの間違いなのでは?と言いたくなる。
Debian はボランティアベースで行っているから、
極端な場合、社長の鶴の一声で意思決定が可能な
商用ディストリビューションに比べて
意思決定も難しいだろうし
ボランティアが忙しければ
作業が進まなくったって全然おかしくない。
# って、ボランティアの認識合ってるのかな?(^^;;;)
少なくともボランティアでやってもらってるものを
使わせてもらってるんだから自己責任で選択し使用すべきだ。
足らない部分に業を煮やすなら
自らボランティアを買って出るとか
資金援助するって手段も可能なわけだし。
それも嫌なら素直に他の選択肢を探せば良いだけの話。
いちいち Anonymous Coward になってまで
酷評するほどの話ではないと思うのだが、、、
# いや、、、言うのも自由なんだけど、、、
え?私?
未だに potato ですよ。
一応、セキュリティパッチ等は適当なタイミングで流れてくれてるので
思い出したように upgrade 出来てますし、、、
導入時は Debian が一番楽できそうだったので選んだのですが
RedHat の方が楽できるのならいつでも乗り換えますけど何か?
uxi
Re:激しく同意!! (スコア:1)
短すぎるということもないでしょうが、思ったよりは短いですね。
セキュリティアップデートだけでも半年くらい続けてくれると、ありがたいんですけどね。
Re:激しく同意!! (スコア:1, 興味深い)
寝惚けるな。明らかに短すぎだ。
と書こうと思ったが、考えてみれば、apt-getでシームレスに次バージョンにアップデートされるのが前提ならそんなもんか。月に一度くらいはapt-getしろよ、しない奴は置いてくぞ、ってことだね。ま、「お客さん」には厳しいシステムなのは間違いないな。
Re:激しく同意!! (スコア:1, すばらしい洞察)
Re:激しく同意!! (スコア:2, 参考になる)
横からコメントですが、potatoに限って言うと、Xが3.3.6なので今時のGeforce系ビデオカードが間違いなく全滅なんですね。
で、自分の会社で使うのならX ver.4系の非公式.debをインストールできますが、他社に使わせるとなると、細かいインストールマニュアルを書かないといけません。これはいやらしい。
でも、woodyにしたってGeForce4をサポートできない(X4.2でもサポートしていないからwoodyのせいではない)という痛い事実があります。相手様にビデオカード選択の注文を付けるのを忘れていて泣きました。
Re:激しく同意!! (スコア:1)
サーバ用途以外にもLinux OSを使っているんですね。支障の
無い範囲で良いんですが、どんな用途にお使いなのか興味が
あるので、教えてくれませんか。トピックとは関係ないですけど。
Re:激しく同意!! (スコア:1)
gcc, gtk+, gtkmmを使っています。ソースコードは非公開なので、ライセンスに非常に気を使いますね。gettextを使いたいのですが、GPLなので使えません。代わりとなるコードを書いてたりします。
ツールの完成度はまだまだなので、それを理解して下さるお客様のみに提供しています。顧客数は一桁ですので、あまり参考にはならないですね。それでもdebian普及に貢献したいのでディストリビューションをdebianに指定しているのですが、、、先のような問題に当たってしまうのです。
Re:激しく同意!! (スコア:0, 余計なもの)
なんでこれが『フレームのもと』なのよ>モデレータ
Re:激しく同意!! (スコア:1)
喧嘩売っているようにしか見えませんが(笑)
Re:激しく同意!! (スコア:1)
Re:激しく同意!! (スコア:1)
そのへん歩ってて、知らない人からいきなり喧嘩を売られると僕はイヤっす。喧嘩を売るんでなしに、議論をふっかけてくれ。応じるから。
Re:激しく同意!! (スコア:0, フレームのもと)
負けを認めたわけですね。
バックポートする理由 (スコア:3, 参考になる)
Re:バックポートする理由 (スコア:1)
いっそサーバレスポンスを
Server: Apache/1.3.9(1.3.26 security compatible) (Unix) Debian/GNU
とでもしてくれれば...(^^;
Re:バックポートする理由 (スコア:1, 興味深い)
問題になるのは、バージョンアップに伴って設定ファイルのフォーマットが変わるとき。
例えば、apacheは1.3.11以降、httpd.confだけあれば事足りるようになったけど、potatoで今でも使われている1.3.9はaccess.confやsrm.confを必要とする。まあ、httpd.confにAccessConfigやResourceConfigを書けばいいことではあるけど、httpd.confは1.3.12以降もバージョンアップを重ねるたびに細かいところが変わってたりするので、最新apacheのhttpd.confに変えるにはscratchから起こした方が早いなんてこともある。こうなっちゃうと、パッケージを使うメリットってbug/security fixだけになっちゃうし、パッケージ使わないとDebianの魅力が半減します。
woodyが安定しているのは理解できているのですが、正式リリースじゃないと(担当者自らがriskを背負うと言っても)上が首を縦に振ってくれない現場もある。かといって現行の正式リリースではパッケージが古すぎて使えない。Debianを業務用途に推すためには決め手に欠けているというのが現実で、この一年間かなり歯痒い思いをしています。
バージョンアップに付随する作業 (スコア:1)
たぶん Apache だけだとそれほど大変ではなくて (パッケージによると、設定ファイル移行を補助するスクリプトがついてきたりします)、ディストリビューションのバージョンアップの際にはたくさんのソフトウェアがバージョンアップするので、それらのうち設定ファイル等の移行作業が必要なものを洗い出し、洗い出した全てについて以降作業を行う、というところが大変だと思います。
こういう場合の対処方法としては、少しずつバージョンアップする、という方法があります。apt-get -su upgrade でバージョンアップが必要なパッケージの一覧 (ディストリビューションのバージョンアップに際しては、たぶん全部になります) を表示し、そのなかから「今日はこれ、明日はこれ」というふうに徐々にバージョンアップしていくのです。依存関係のため、多数のパッケージが一気にバージョンアップしてしまうこともありますが、作業の分散にはちょっとは役立ちます。
ちなみに、こういう方法をとったとき、いつの時点をもってシステムが新バージョンに移行したとみなすか、というのは決まっていません。/etc/debian_version というファイルが base-files パッケージに入っていますが、これは単に数字を記憶しているだけのファイルですし。(気分的には、libc のバージョンアップをもってシステムのバージョンが上がったとみなすのがよさげ)。