[pgsql-jp: 31279] Re: configureのオプション確認

Misha misha @ mbm.nifty.com
2003年 10月 23日 (木) 23:57:06 JST


こんばんは。ミーシャです。

話をさらに脱線させるようで恐縮ですが(いっそタイトルごと変えてしまった方がよいか?)、
私も、後藤さんの意見に賛成ですし、それ以上に、ある種の危惧すら抱いています。

元々オープンソースは、その名の通り、「ソースを書き換えることすら」できてしまうわけなので、
(今のご時勢では、いささか極端な話になってしまいますが)
せめて、元のアーカイブファイルと、configure でどう設定したか?
ぐらいの保管はしておくべきであろうと思います。

さらに、「パーソナルサーバ」ならまだしも、
多くの人によって開発の手が加えられ、
また、引き継がれていくケースの割合が圧倒的に高いでしょうから、
ことは「本人の責任」のみでは済まない、と考えるのが妥当であると思います。

特に configure を手入力で行い、ソースまできれいに後始末してしまった場合など、
もし、これを、何れ見知らぬ誰かが引き継ぎ、何かの理由で、どう構築されたかを知る必要が生じたとき、
きっと、その「誰か」は、バイナリデータとして残された情報と、自らの推測に頼らざるを得ず、途方にくれてしまうことでしょう。
(業務系に限らず、「公共物としてのサーバ」については、万事において言えることと思います)。

ちなみに私の場合でいえば、configure を含め、make 自体も、
全てシェルスクリプトで書き、それを実行させるようにしています。
また、DB構築の基本的な部分も、psql コマンド等を、
そのシェルスクリプト(あるいはSQLスクリプト)から実行させるようにしています。
そして、展開前のアーカイブファイルとそのシェルスクリプトファイルを同梱してバックアップを取っておきます。
これは、大仰な言い方ですが、こうしたインストーラを作っておくことを個人的な「ルール」にもしています。

理由は3つあります。
1.器用ではないので、1回では、手入力だけで全て思うとおりにコンパイル・インストールができない(苦笑)。
2.同じ環境下でのクリンインストール時は無論のこと、別な環境下でも、ほぼ同様の構築が保証される。
3.(そして、これが一番大きいことですが)コンパイル・インストール(加えてその後の設定まで)の
  「ドキュメント」が残る。
といったところです。

手前味噌ですが、これは多くの方にお勧めしたい方法です。
本人が楽なだけでなく、半年後の(ことによっては1月後の)「見知らぬ誰か」のためでもあるからです。

--------------------------
ミーシャ

> -----Original Message-----
> From: pgsql-jp-admin @ ml.postgresql.jp 
> [mailto:pgsql-jp-admin @ ml.postgresql.jp] On Behalf Of Kazumasa Gotoh
> Sent: Thursday, October 23, 2003 6:22 PM
> To: pgsql-jp @ ml.postgresql.jp; naitotk @ mars.dti.ne.jp
> Subject: [pgsql-jp: 31276] Re: configureのオプション確認
> 
> 
> From: Takashi Naito <naitotk @ mars.dti.ne.jp>
> Date: Thu, 23 Oct 2003 18:03:00 +0900
> 
> > 余談ですが、Buildした際のソースツリーを消してしまった場合、確認の方法は
> > あるのでしょうか?
> 
> それはものによるでしょう。PHP はロードモジュールだけになっても
> 確認が可能で、PostgreSQL も pg_config --configure で確認できる
> ようです。
> 
> ただ、私は一般的に言って、ロードモジュールしか残っていない時に
> どう configure したかは、わからないものの方が多いと思います。
> 
> これはそもそも「そんな事がわからなくなるというのは、本人が悪いだけ」
> という事があると思うからです。
> 
> 管理者たるもの、その程度の事はわかるように情報の管理を行うのが
> 当然の事ですし、多くのものはそのプログラムの動きからどのような
> オプションを指定したかは大抵の場合には判断できるものです。
> 
> PHP や PostgreSQL で後日確認ができるようになっているのは、
> 指定パターンが非常に多く、プログラムの動きから判断するのが
> 難しいのと、そういう問い合わせを頻繁に行う管理の悪い人が
> 多く使うようになってきたからではないでしょうか。
> 
> PostgreSQL でも pg_config が出てきたのは 7.1 からですし。
> 
> ただ、Linux の RPM パッケージみたいなものをそのまま使うような
> 場合には、「はて?」と思う場合がありますけど、pg_config が
> 追加されたのは、そのような事とも無関係ではないかも…
> 
> もっとも、私は PHP や PostgreSQL のように configure オプションが
> 非常に多く、それによりプログラムの動きが大きく変わるようなものは、
> バイナリパッケージを使わずに、必ず自分で make する事にしています。
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> (株) セントラル情報センター
>                              後藤和政    kgotoh @ cic-kk.co.jp
> 
> 





pgsql-jp メーリングリストの案内