• ベストアンサー

debianで最新(or任意の)バージョンをパッケージをインストールする方法

debian 3.1r4 (sarge) を使用しています。 パッケージ管理は aptitude を使用しています。 メールサーバーに postfix を選択すると、2.1.5-9 がインストールされます。 これで運用していましたが、postifxの 2.2以降を使用する必要に迫られています。 どのような操作をすれば新しいバージョンをインストールできますでしょうか? (ソースのリコンパイルならできますが、それでなくて、  できるのならちゃんとパッケージ管理システムを使って管理したい) 試しに souce.list を書き換えて stable を testing にすると 2.3.3-1 が選択可能になりましたが、インストールしようとすると 「展開後900MBもの大量のファイルをインストールするが良いか?」 という旨のメッセージが表示されるため、今のところやっていません。 (もし余計なものまで最新の testing版にされるなら本意ではないので) よろしくお願いいたします。

質問者が選んだベストアンサー

  • ベストアンサー
  • heiwa4126
  • ベストアンサー率69% (9/13)
回答No.6

backportsプロジェクトには今のところpostfix 2.3.3まであるようです。 詳しくは"backports.org"で検索してみてください。 (たぶんhondan999さんならこのヒントで十分だと思う)

hondan999
質問者

お礼

とり急ぎ、ご紹介いただいたページの Introduction まで読みました。 ・・・そのものスバリのニーズに応えたサイトのようですね! すばらしい。 やはり同じニーズはあるわけで、対策は共有されているという所でしょうか。 ありがたい話です。 来月、またリリースがあるようなので、それで2.2以上にならなければ、 試して見たいと思います。 また、今後も他のパッケージで同様の状況にならないと限らないので、 今のうちこのサイトを情報を把握して、備えておきたいと思います。 ありがとうございました!

その他の回答 (5)

  • kalze
  • ベストアンサー率47% (522/1092)
回答No.5

2.2以降にする期限までまだ間があるようなら、一応etchのリリースが来月ってことになっているのでもうしばらく様子を見て待ってみるのも手。 普通はただ単にソースをコンパイルして入れるだけってのはやらないとおもいますが。 使わなくなったときに削除するのが面倒だし。 どうしてもなら、2.2以降のソースを落としてきて、それからdebパッケージを作るでしょう。 Debianだとdebパッケージだし、RedHat使っているならrpmパッケージだし、パッケージシステム採用しているディストリビューションを利用している場合、やむにやまれぬ事情がある場合はそうするかと。 パッケージの作り方はネットでも書籍でも情報はでているし、そこまで大変ではないし。

hondan999
質問者

お礼

来月、次のリリースですか、それなら待てない期間ではないですね。 (最新の2.3に対して、Debianは2.1でしたので、こりゃ全然更新されてない?  と絶望的になって、次のリリース日とか調べる以前に代替手段を探していました) 期待していいのか分かりませんが、せっかくですので本件に関しては 次のリリースを見てから代替手段を講じるか判断しようと思います。 >普通はただ単にソースをコンパイルして入れるだけってのはやらないとおもいますが。 賛成です。 > どうしてもなら、2.2以降のソースを落としてきて、それからdebパッケージを作るでしょう。 なるほど、nizakana321さんからも提案いただきましたが、 どうしても必要な時は強引に入れるんじゃなくて、パッケージを作って入れるわけですね。 これは非常に納得の行く話です、スッキリしました。 仰るとおりパッケージ作り方はここで手取り足取り教えていただく前に、 自分で検索して調べる余地が多々ありますので、checkinstallも含め、 勉強してみますね。 ありがとうございました。

回答No.4

No.2です。 パッケージ管理で,というのであればcheckinstallというものがあります。 http://www.google.com/search?q=checkinstall&btnG=Google%E6%A4%9C%E7%B4%A2&hl=ja&ie=UTF-8&oe=UTF-8&filter=0 これはソースからdebもしくはrpmパッケージを自動的に作成してくれます。 ただ,前述したとおりインストールする時点で依存関係回りで引っかかる可能性はあります。 が,やってみる価値はあるでしょう。覚えておいても損はないと思います。

hondan999
質問者

お礼

なるほどまずパッケージ形式を作って、それから入れれば、 少なくとも管理はパッケージベースを維持できる、ということですね。 後はそのものが上手く動くかどうかと。 参考になりました、ありがとうございます。

  • mtfoggy
  • ベストアンサー率14% (37/255)
回答No.3

>(ソースのリコンパイルならできますが、それでなくて、 > できるのならちゃんとパッケージ管理システムを使って管理したい) > 困ったなぁ・・・ なぜ、ソース版がイヤなのでしょうか? ただ単にコンパイルするだけですが。 スキルがあれば、まったく困る必要はありません。

hondan999
質問者

お礼

> なぜ、ソース版がイヤなのでしょうか? それ言ったら、なぜパッケージとかあるの?って話しですよ(^^;;; > スキルがあれば、まったく困る必要はありません。 そのあなたのお持ちのスキルを頼りに質問しております。 よろしくお願いいたします。 「単にコンパイルするだけ」でホントに問題無いと言い切って もらえるなら、それはとても安心です。 そうではなくて「パッケージと同じようには行かないよ、 入れて動かすだけならいいけど、後の事考えたら、 必要に応じて考慮する事はいろいろあるでしょう、でも、 それもスキルの内!」という意味でしたら、 おしえてgooの回答としてはちょっと困ってしまいますよね・・・ どっちですか? 私もソース配布しか無かった時代の人間ですから、 「ソースがなんでイヤなの?」とか言いたい気持ちも分からんではないですが、 時代も変わってますし、パッケージというシステムがあるなら、 それを上手に使って運用できれば越した事無いですよね。 で、結論として、こういうケースでは「ソースから入れるのが一般的」 という事でしたら、それはそれで良いのですが、今後のパッケージ管理や更新と 競合が起きないのか、ソース導入とパッケージ管理のごちゃまぜの際に 気をつける点があるのか、無いのか? 疑問に思います。 「ソースをコンパイルしてインストールするスキル」というより、 やっぱりdebianパッケージ管理を良く知る必要があるかと思います。 私はこの辺のスキルが正直無いです。逆にdebianを使ってきた皆さんなら 当たり前に直面する問題で、一般的な対応方法が確立しているだろうと考えましたので、質問させていただいたということです。

回答No.2

http://debian.fam.cx/index.php?AptGet#content_1_13 こういう方法はありますがあまりおすすめはできません。 おそらくlibcなどかなりコアな部分も更新する必要が出てくるでしょうから、 stableはstableのまま使うべきでしょう(もしくはソースからインストールですかね)。 また、stableからtestingの様にバージョンをまたいでアップグレードすると色々と問題が出てくる 可能性が高いので、アップグレードする場合はテスト環境を作るなどして十分検討してください。 私の場合、Debianはデスクトップ・サーバの両環境で使用していますが、同一バージョンのアップデートでさえ 挙動やサービスの設定がガラッと変わることが多々あります(testing環境なのでなおさらかもしれませんが)。

hondan999
質問者

お礼

やっぱり自動管理は「そこまで」という感じなのでしょうか? postfixは2.2以降でないと使えない機能があるのですが、 世界中で使われている debian + postfix の管理者の方は 皆、キケンで裏ワザ的な導入に踏み切らざるを得ないのでしょうか? 自分が知らないのはお恥ずかしい限りですが、知らないなりにも 「これでunixユーザーが納得するはずが無いから、  これだけ普及したシステム(debianのパッケージ管理)なら、  なんか方法があるのだろう(自分が知らないだけだろう)」 と思って質問させていただきましたが・・・うーん。 快適+安心感を享受していましたが、さっそく限界にあたってしまいました。 困ったなぁ・・・

noname#39970
noname#39970
回答No.1

debianがちゃんと動作検証してstableとして出して初めて上のバージョンが出てくる。 というのは判ってると思う。 stableのリリースが待てない人はtestingにするかソースから、と確かどこかに書かれていた。 気持ちは分るけど。パッケージ管理のまま行くなら待つかtestingという選択に迫られると思う。

hondan999
質問者

お礼

ありがとうございます。 postfix が testing なのはOKですが、他を巻き込むのは困ります。 #ライブラリの依存関係など、理由は理解できますが・・・ せめて特定のパッケージだけ一時的に(自己責任で)ソース導入にする場合に、 パッケージ管理から一時的に除外でき、上手く行かない場合や、 後日、パッケージが更新された場合には、またパッケージ管理に 戻れせるとか、そういう運用があれば・・・と思いますが。 パッケージ管理と stable リリースの安心感から 今回、Debian に切り替えた(今までRedhatで手作業が多かった)のですが、 なんと言うか、パッケージ管理を維持すると「全てが与えられたもの」に 限られてしまうのは、unix的には残念というか、極端ですね・・・

関連するQ&A