こんにちは，deb パッケージの作り方はこれから勉強予定なので，
詳しい方の書き込みを読んで私も学んで行きたいと思っています．

uchan21さん による投稿:

■make; make install でインストールする：

GNU 標準に準じ counfigure スクリプトが用意されている場合，
インストール先を自分のホームディレクトリの中に指定できます．
例えば，$HOME/foo にインストールするとして，大まかには次の3つのコマンドで OK です．
(補足：HOME はホームディレクトリの絶対パスを示す環境変数です．）

$ ./configure --prefix=$HOME/foo
$ make
$ make install

出来た実行ファイルのシンボリックリンクをパスの通ったディレクトリ(ここでは$HOME/bin)に作ります．
(補足：$HOME/bin を作成して置くと，次回ログインから .profile がパスを通す処理をしてくれます．)
$ ln -s $HOME/foo/bin/* $HOME/bin

アンインストールは $HOME/foo を削除します．
$ rm -rf $HOME/foo
後，無効なったシンボリックリンクを $HOME/bin から消去します．

ルーチンワークとなっているので，ソースのダウンロードと展開を含め，
シェルスクリプトを作成して特殊なパッケージ（クロスコンパイラ等)をインストールしています．

バージョンアップは新バージョンのソースを取ってきてもう一度インストールが基本です．
新バージョンが出たとの情報は自分で収集します．独自 deb パッケージを作ったとしても同じことでしょう．

メリット：
インストール，アンインストールを含め，すべて一般ユーザ権限で実行可能(sudoはいらない)であり，
システム全体にはほとんど影響が無い．システムを破壊する恐れが少ない．

デメリット：
依存関係はすべて自分で管理しなくてはならない．ライブラリのインストールには不向き．
ライブラリをこの方法でインストールした場合，それに依存するパッケージの configure に明示せねばならないし，
実行ファイル(ダイナミックリンカ)に共有ライブラリが特殊な場所にあることを伝えないといけない．それなりの知識が必要．

補足：
UNIX が現在の ubuntu の様にパーソナルユースで使われることが無かった時代からの由緒深い方法です．
ユーザそれぞれがスーパユーザ権限を持つことは有りませんでしたから．

最後の編集者: einundzwanzighundertsechs (2009-03-04 14:39:23)

einundzwanzighundertsechs様　

ソースからのインストール方法を詳しく解説していただきましてありがとうございます。

バージョンアップは新バージョンのソースを取ってきてもう一度インストールが基本です．
新バージョンが出たとの情報は自分で収集します．独自 deb パッケージを作ったとしても同じことでしょう．

今回は、checkinstallで対処したいと思いますが、やはり、正規のリポジトリ登録パッケージでない以上、
こういう知識を持った上でやることが重要ということですね。

uchan21 による投稿:

”Debian用”と指定され、「XXX.deb」というファイル名で公開されているパッケージも、Ubuntuで
インストール自体は出来ると思いますが、実際にちゃんと動作するものでしょうか？

動作することも多いですが、破滅的なトラブルを引き起こす可能性もあります。
ソースパッケージがあればリビルドすることで多少マシになりますし、リビルドはたいした手間ではないのでやり方を覚えると良いでしょう。

# 具体的な手順は敢えて書きません。
# 検索エンジンを活用すればやりかたは出てくるはずです。このあたりを自分で探せないようでは確実に致命的な事態が起きるでしょう。ただ、出てきた情報が正しいかどうか、という点については回答したいと思いますので、「こういう手順のURLがありましたが、これは言い換えると〜〜〜ということですか？」的な質問であれば真偽はお答えします。

このような質問をさせていただくのは、目当てのアプリケーションソフトウェアで、ソースとDebian用パッケージ
の両方が公開されている場合に、ソースからcheckinstallで作成したパッケージを使うべきか、Debian用
パッケージを使うべきか、判断がつかないためです。

Debianのソースパッケージがあるならそれをリビルドし、なければcheckinstallしてください。バイナリのままDebianパッケージを導入するのは、ほんとうに最後の手段です（少なくともやるならシステムの再インストールの覚悟が必須）。

uchan21さんへ，重点の置き場の違いが混乱の元ではないですか？
最初の投稿でリスクについて触れられていますがその後の投稿では--

uchan21さん による投稿:

インストールしたソフトウェアが
きちんと動作するという最低限の用件を満たしているか否かという観点での違いがあるか？

私は、「Debian用パッケージ（XXX.deb）」がそのまま使えるなら一番お手軽でいいかな

１と２は同等だと思っていましたので、アンインストールのやりやすさを考えて、checkinstallにしようと思っていたのですが、

経験者はシステムに障害を与えることを第一に恐れます．以下それが伺える部分の引用です．

yamaさん による投稿:

出来たパッケージを他者に配布するということには向いてないし、迷惑なのでしてほしくないのですが、
　
   どちらにしろパッケージ管理が複雑になり、Ubuntuのメジャーアップデートの時にトラぶったりとか、リスクが増える可能性もありますので、

hitoさん による投稿:

動作することも多いですが、破滅的なトラブルを引き起こす可能性もあります。
ソースパッケージがあればリビルドすることで多少マシになりますし、

バイナリのままDebianパッケージを導入するのは、ほんとうに最後の手段です（少なくともやるならシステムの再インストールの覚悟が必須）。

ついでに私(も経験者の一人だとして） による投稿:

インストール，アンインストールを含め，すべて一般ユーザ権限で実行可能(sudoはいらない)であり，
システム全体にはほとんど影響が無い．システムを破壊する恐れが少ない．

複雑なインストールの手順が「危険な」操作ミスを誘発することがよく有ります．
簡易であることを目指すのは決して間違っていません．

個人的には「スーパユーザ権限で作業することの危険性」を強調して置きます．
deb パッケージのインストールも sudo して行うので本来危険なのです．
ソースパッケージからのリビルドで少しだけ安全になります．
伝統的なパッケージのインストールが make と make install に分けてあるのもリスクを最小に抑えるためです．

追記：ack さんの投稿を読んで，当然と思っていろ語感が通じない可能性が有ることに気付きました．有り難うございます．
上記3行では，
「deb パッケージ」  = Debian のバイナリパッケージ
「ソースパッケージ」 = Debian のソースパッケージ
「伝統的なパッケージ」 = いわゆる tarball
のつもりでした．

最後の編集者: einundzwanzighundertsechs (2009-03-07 07:22:35)

私なりに2点ほど。

まず1点目：
checkinstallは確かにアンインストールは楽ですが、インストール時に思わぬリスクもあります。
既にシステムにインストール済みのパッケージと「同じ」パッケージ名でcheckinstallを実行してしまうと、システム上のパッケージ状態が崩れてしまう事がある、というリスクです。
私は過去に不注意で、pythonがインストール済みなのに、より新しいバージョンのpythonをpythonという同名パッケージ名でcheckinstallしてしまうという大失敗をしました。
ただ幸運にも仮想環境のゲストOSだったので簡単に元に戻せました。
checkinstallする際はパッケージ名の衝突に十分注意してくださいね。
# 個人的には、checkinstallはかなり好きなツールです。

次に2点目：
実ホストであれこれ実験的な事をやるのは本質的にリスクがあると、私は思っています。
その為、ソフトウェアのビルド、ならびにビルドしたソフトウェアの使用については、極力仮想環境のゲストOS上で行っています。
例えば、仮想環境のゲストOSでソースビルドしたffmpegをゲストOS上で使うという運用です。
これだと、ホストOS側を汚したり壊す心配も一切なく、ソースビルドしたソフトウェアの恩恵を受けられます。
仮想環境のゲストOSだとスナップショット機能で元の状態に戻すのも簡単なので、色々と便利です。
仮にインストールに失敗してしまっても平気ですし、気が変わって辞める時もすぐに元に戻せます。

最後の編集者: STGSAGWAN (2009-03-06 20:16:15)

einundzwanzighundertsechs様、ack様、STGSAGWAN様　ありがとうございます。

私は単純な話だと思って気軽に質問してしまったのですが、かなり奥深い問題だということがよく分かりました。
アドバイスいただきましたことは、全部は理解出来ていないのですが、理解するためには、私自身がもっと
経験を積む必要がありそうです。

さて、ここで、具体的に私が何をしようとしているかについて、もっとお伝えする必要性を感じました。

openSIPSというソフトウェアをインストールしたいと考えています。ところが、Ubuntuのリポジトリには登録されていません。
したがって、openSIPSのサイトからダウンロードしてきてインストールしようと考えました。
このサイトには、Debian用パッケージもあれば、ソース（Debian用のソースではなく、一般の（？）ソース）もあります。

この状況に直面し一連の質問をさせていただきまして、次の３つをインストール方法の候補としました。

１．ソースからmake; make install
２．ソースからcheckinstallでパッケージを作成して、dpkgでインストール
３．Debian用パッケージをdpkgでインストール

その後、さらに質問をさせていただき、３は却下、１と２を比較して、sudoを使う回数、パッケージ名衝突リスク等を考慮すると、
１が最も安全という結論を得ました。（あってますでしょうか、、、汗）

以上を踏まえまして、openSIPSのインストールについて、今回の私の対処としては、１が最も安全ではありますが、アンインストールの
しやすさを優先して、パッケージ名の衝突に気を付けてcheckinstallを使う、つまり２の方法で進めることにしようと思っています。
どうも、ありがとうございました。

最後の編集者: uchan21 (2009-03-07 14:46:03)

einundzwanzighundertsechs様　ありがとうございます。

einundzwanzighundertsechsさん による投稿:

最初にそうして下されば展開は違ってきたと思います．uchan21 さんがどうシステムを運用しているのかも必要です．
-- 試験用で無理がきくなのか，業務用でシステムの停止が致命的なのか --
一般論としては威すぐらいがちょうど良いと思いました．薬が効きすぎたでしょうか？

そうですね。。問題が単純だと思い込んでいて、一般論で質問してしまいました。申し訳ありませんでした。
もう遅いかもしれませんが、私のシステム運用ですが、”試験用で無理がきく”です。最悪、OSの再インストールとなっても
誰にも迷惑はかからない環境です。

einundzwanzighundertsechsさん による投稿:

具体的に何が予防策になるのかを一番教えてくれたのは失敗でした．
make install でやらかした私の失敗例：

分かる気が致します。
それにしても、怖いトラブルが起きてしまうものですね。
貴重な情報をありがとうございました。

einundzwanzighundertsechsさん による投稿:

openSIPS について質問したい場合はパッケージ名入れたスレッドを立ててください．

実は、chekcinstallを実行してみたんですが、いろいろとエラーが出まして結局断念しました。
それで、make; make install;でやっているんですが、makeで、エラーが出てしまって、どうしても
compileできないモジュールがありまして、質問を続けたいところですが、別スレッドを立てさせていただきます。