pukiwiki.ini.phpなどの設定ファイルは別名で配布して欲しい†
- ページ: BugTrack2
- 投稿者: ELF
- 優先順位: 低
- 状態: 提案
- カテゴリー: 本体バグ
- 投稿日: 2005-03-16 (水) 00:58:18
- バージョン:
それぞれに--move-dist, --copy-distオプションを追加。リリースパッケージを作成する直前に、その中にある設定ファイルを加工する。
- --move-dist: *.ini.php があったとき、*.ini-dist.php にリネームする
- --copy-dist: move-distの処理を行った上で、 *.ini-dist.php を *.ini.php へコピーする
release_update.sh はついでに -d オプション(CVSROOTを変更する), --zip オプション (*.zipパッケージを作る) に対応。
$ sh release.sh
Usage: release.sh [options] VERSION_TAG (1.4.3_rc1 like)
Options:
--nopkg Suppress creating archive (Extract and chmod only)
-z|--zip Create *.zip archive
--move-dist Move *.ini.php => *.ini-dist.php
--copy-dist Move, and Copy *.ini.php <= *.ini-dist.php
$ sh release_update.sh
USAGE: release_update.sh [options] VERSION_FROM VERSION_TO (VERSION = '1.4.3_rc1' like)
Options:
-z|--zip Create *.zip archive
--move-dist Move *.ini.php => *.ini-dist.php
--copy-dist Move, and Copy *.ini.php <= *.ini-dist.php
メッセージ†
pukiwiki.ini.phpなどがそのままのファイル名で配布されると
気をつけないと既存の設定ファイルが上書きされてしまうので，
別名で配布して欲しい．
少なくともupgradeのtarballは．
#wikiディレクトリなどは最悪バックアップから戻せるのかなー
ちょっと確認: update_XXX.tar.gzとは†
- 現状の update_XXX.tar.gz は「バージョン間で修正が入っているファイルを抜き出したもの」で、それ以外のものではありません。 -- henoheno
- update_XXX.tar.gz は以前から手作業で用意されてきたものであり、ニーズが読めないものであったため、PukiWiki 1.4.4のリリース当初はリリースするつもりがありませんでしたが、official:PukiWiki/Dounload/1.4.4 での要望を受けて用意したものです。 -- henoheno
コメント†
- CVS環境があるなら自動でマージしたり手動で修正できたりするのでなにかと便利ですのでお勧めです。 -- Ratbeta
- それ*1はそうだと思いますが、ELFさんはそういうことを言ってるんじゃないと思います。フェイルセーフというかフールプルーフというか、イージーミスを起こしにくくさせる気配りが欲しいということなんだと思います。 -- okkez
- 通常、同じファイルを pukiwiki.ini.php 以外のファイル名で提供するとかの感じですよね。わたしのところではそうしています。 -- みこ
- 質問の意図は理解していましたけれども。要するにphpのphp.ini-distみたいなあれですよね？それだとCVS環境での同期が取りにくくなる問題が出てくるんじゃないかと思います。upgradeのみなら問題はないと思いますけれども。 -- Ratbeta
- そう、それですよ＜php.ini-dist.php。でも、CVS上ではpukiwiki.ini.phpのままでrelease.shでパッケージングするときにリネームすれば済む話だと思いました*2。 -- okkez
- そういう話．CVSはある意味一旦どうでもいいんですが，tarballで設定ファイルを上書きの危険性は可能な限り避けられる方が好ましいと考えます．例えばwikiディレクトリとかはpukiwiki.ini.phpで別のディレクトリ名にしたら間違って上書き!!ってのから逃げられるんですが，pukiwiki.ini.phpなどの*.ini.phpはコアをハックしなければそうはいきません*3 -- ELF
- うーん、そこまで「tarball を展開して上書き」という運用を推奨されたいのですか・・・ (^^; -- henoheno
- お疲れ様です。それぞれのページに、現状の分析(最初は仮定でいいじゃないですか)と期待されるモノとをそれぞれ整理しながら進めて下さいませんか (^^; -- henoheno
- さて、moveかcopyかという話みたいですね。 -- henoheno
move (設定ファイルをうっかり上書きしない様にどけておくのはどうか)†
- 現状の update_XXX.tar.gz は「バージョン間で修正が入っているファイルを抜き出したもの」で、それ以外のものではありません。 -- henoheno
- これに対しELFさんは何か特定の運用を期待されている様ですね。上に書いた通りで update_XXX.tar.gz は「各自が実運用しているPukiWikiに上書き展開しろ」と言う代物ではないのです。「move して pukiwiki.ini.php というファイルを無くせ」という提案は、現段階では特定の活用事例のみに根ざしたものであるように見受けられます。 -- henoheno
- っていうかふつー「update_XXX.tar.gzってアップデート用アーカイブ」って思いませんか? 上記のような目的ならかなり強く別名にすることを提案します -- ELF
- 単にファイルの差分を見たいなら技術的には旧tarballと新tarballの差分を取り出せばいいだけです*4．仮に「差分を確認したい」と「アップデートを簡単にしたい」の活用事例があったとして，どちらの方が比重は高いと思いますか?
- また、通常のパッケージに対しmoveを適用した場合、PukiWikiの設置にあたって一手間かかることになってしまいます。具体的には「入手して展開して即動く」という大きな利点が失われるのですが、それについてどうお考えですか。 -- henoheno
- そもそもupdate_XXX.tar.gzを使っての更新はサポート対象外のような気がします。単純にファイルがちぐはぐになったりする可能性もありますし、そうでなくても動作に問題が出る可能性があります。 -- Ratbeta
- BugTrack2/12のELF的感覚の用語をあえて使うとして，その前提だと「アップデート」は殆どの場合，上書きのみで済むはずです．すまないものは「アップグレード」で仕様が変わっているから．まぁ当然100%な話ではないですが(苦笑 また，PukiWikiは現在「アップグレード」のものはリリースされても「アップデート」のものはあまりリリースされないので当然問題が出てくる可能性は非常に高いです． -- ELF
- うーむ、現在の update_XXX.tar.gz を既存のPukiWikiに重ねがけ(上書き)して、それで「アップデート」/「アップグレード」が成功するはず、とされる主張は、update_XXX.tar.gz が何であるかに対する誤解と、運用方法に関する仮定に根ざしていらっしゃるように思います。tar.gzの中身でいきなりファイル単位に上書きしてしまうような(乱暴な)運用は、「仕様が変わっていなければ成功する」とか、「あるレベルの仕様変更で失敗する」などというモノではありませんので、仕様変更の有無や規模に関する主張とは全く関係が無い様に思います。 -- henoheno
- なお、update_XXX.tar.gz の「update」という名前が誤解を与えるかというと、そんな事は無いでしょう。普通は「これはどういうものか」を知ろうとしますから、「1.4.4と1.4.5_1の間で修正／追加されたファイルのみ」といった説明を見てその意味を理解されるでしょう。 -- henoheno
- SourceForgeから入ってPukiWikiプロジェクトのページに行き，Downloadからダウンロードしようとした人はどうやってその情報を知ることができるのでしょうか? -- ELF
- そのルートからファイルを見た人にとっては、ファイルが何者であるのかは現状ノーヒントです。これに対する提案であれば、まずはヒントを掲載する(ファイルの中か、ファイルリリースの説明の部分に)という対策が取れるでしょう。なお、注意深い方なら、展開したパッケージの中身を見たり、orgサイトを見たりするでしょう。「ノーヒントのパッケージを勝手に判断していきなり上書き展開する」方に必要なのは誤解を生まない情報や、ほんの少しの注意深さです。設定ファイルをどけておく事ではありません。 -- henoheno
- 「1.4.4と1.4.5_1の間で修正／追加されたファイルのみ」という表現からは、ELFさんの仰るように「じゃあこのファイルだけ上書きすればアップデート完了だな」と思うユーザがいてもおかしくないと思います。定義なりファイル名なりを変えるおつもりがないのならば、それこそユーザに「誤解」させないように「これをそのまま上書きしてアップデートはしないでください」とでも明記しておくべきかと思われます。 -- sagen
- 「安直な」ファイル単位の上書き行為 がなぜ良くないのかは、影響範囲を明確にすれば明らかです。同じ名称のファイルは全てリセットされ、移動されていた場合の古いファイルは消されずに残り、カスタマイズを行ったコードがあった場合は結果的に予測できない不整合が発生する可能性があります。 -- henoheno
- 設定ファイルの類 (少なくともadminpassはリセットされる)
- wiki/ 以下 (所定のデフォルト文書と同名のページがリセットされる。PukiWiki 1.4.5 における「プラグインマニュアル」のように、文書名の変更があれば、だぶる)
- cache/ 以下 (リセットされる/現状と相違が出る)
- .htaccess (リセットされる)
- plugin/ 以下 (削除したはずのプラグインが再び配置される可能性がある/カスタマイズがリセットされる)
- lib/ 以下 (行ったはずのカスタマイズが打ち消される可能性がある/カスタマイズが中途半端に残り、致命的な不整合が生じることがある)
- 自分が何をやっているのかが解っている方や、慎重な方には全く問題にならないでしょうから、「上書きするな」と明記するのはまた別の意味で正しくないでしょう＞ sagenさん -- henoheno
- 「安全側に傾ける」という意味では「上書きするなorしない方が良いよ」というのは正しいのではないでしょうか？ -- okkez
- 一言では今回のように勘違いに根ざした問題の歯止めにはならないと思いますので、update_XXX.tar.gz に関する説明書きがもう少しあると良いのでしょうね。(このBugTrackがそうなるかも) -- henoheno
- 「自分が何をやっているのかが解っている方や、慎重な方」以外の人≒初心者の為に、せめて注意書きを書いてはどうかと提案したのですが……。(^^; -- sagen
- update_XXX.tar.gz がどのようなものかは上にまとめた通りで、どう料理する(どのような手順で利用する)かは各人次第です。情報が足りないというのであれば補いましょう。しかし今ある道具の存在に納得されないのはなぜですか? 特定の運用を過程した変更を加えた場合、かえって問題となる運用が存在するかもしれない可能性を考慮されないのはなぜですか? また、希望に添った新しい道具を作ろうとか、その実現可能性について話を進められないのはなぜですか? 現状をふまえずに誤解に基づいた提案を突き進める前に、今一度ご検討をお願いします。 -- henoheno
- update_XXX.tar.gz は私が参加する前からこのような内容であったものなので、誤解なきよう。 -- henoheno
- 今ある道具の存在に納得するというか「現状のものまずいんじゃないの?」の指摘であって，現状のものは「常に納得しなければならない」なら当然バグと新規機能要求などを除いた「改善要求は何もいらないわけです」で，そういった考えははあるのでしょうか?(ないはずと思っていますが)また，別の方向性への「提案」なので当然現在の方向性がっちりで使っていればいるほど問題が出る可能性はあるでしょう．そして，「まったく問題がない」のであれば私以外に「問題があるのでは」と考える人は居なかったはずだと思いますが，現実は程度の違いはあれど問題視している人は少なからず居ることは事実だと思います -- ELF
- updateのtarballができたときになぜ指摘しなかったか? というと，そもそもpukiwiki.orgのダウンロードはいつも迷子になるので使わずにsf.jpからのダウンロードばかりしていました*5，sf.jpのファイル情報は以前*6までファイルライブラリとしてのコンテンツはほとんどなく*7特にプロジェクトトップページからはupdateのtarballは出てこなかったので単に「知らなかった・認識していなかった」だけです．henohenoふぁんにファイル管理を編集していただいたこともあり，着目しようとして今回問題があるのでは? と考えたわけです．つまり最初から知ってたら最初から言ってるわけです． -- ELF
copy (設定ファイルの控えを残しておくのはどうか)†
- みこさんの実践されている、pukiwiki.ini.php の copy を pukiwiki.ini-dist.php という名前で残すというアイデアはそれなりに有効(親切)だと思います。実際に多くのサーバー系ソフトウェアがそうしていますよね。 -- henoheno
- PukiWikiの場合 copy について考慮すべきは、既存のパッケージサイズとiniファイルのサイズ(や構成)、そして実際の活用状況をふまえたバランスになると思います。PukiWikiは展開すれば(一部圧縮していますが)1.2MB程度にもなり、例えば10MBしか使えないWebホスティング環境では結構な重荷です。そこに全部合わせて40KB*8の *.ini-dist.php を余計に置きたいのかどうか。またPukiWikiのパッケージは小さく、素早く入手でき素早く解凍できます。なのに *.ini-dist.php を含める意義が本当にあるのかどうか。このあたりについて皆さんどうお考えですか。 -- henoheno
- それは、大局をみてなさすぎ。そういうひとはdistを消すなどの工夫をするので no problemですよ (^-^ -- みこ
- ファイルの頭なり、インストールマニュアルなりに一言「邪魔なら消しても問題ないよ」って書いておけばいいと思います。 -- okkez
other: プラグインを二分する†
- 容量の問題で言うとプラグインの重要度を整理して基本プラグインと拡張? プラグイン的2段階で配布をするほうがいいのではないかと思います*9． -- ELF
- 分けるなら、さらにPLUGIN_DIR を PLUGIN_DIRS という形で設定できると、サイト共有のもの/サイト個別に要求される拡張プラグインの格納場所と使い分けることができて嬉しいと思うのですが、どうでしょう？ -- jjyun
- 標準添付プラグインと自作プラグインのディレクトリを分けるような使い方もできますね。 -- teanan
- プラグインのロード速度に影響しない範囲でお願いしたいですね。 -- Ratbeta
- 脱線気味ですが (^^; 容量の問題にかかわらず、基本プラグインとそうでないものを簡単に分けることができることは良いことだと思います。ベーシックなプラグイン以外のもの(例えばtouchgraphとか)をスパッと削除して、ベーシックな機能しか動作しないPukiWikiがすぐに用意できる状態であれば良いですよね。。 -- henoheno
- PukiWiki 1.3のころはpluginディレクトリの中をスパッと削除しても(newpageを除き)問題なかったのですが、1.4では基本機能もpluginの形に落として単純化されているため、現状のようになっているようです。(当時の名残として、今も cmd=read, cmd=edit という基本機能の呼び出し方法が残っています) -- henoheno
- 現在プラグインのロードは、全てが特定(同一)のディレクトリにあるものとして作られていますので、「pluginディレクトリの中に無かったら、次にここを探す」という機構を追加すれば実現はできそうですね。 -- henoheno
- こんな感じでしょうか? (ロード速度に影響しないかどうか心配ではありますが...) -- jjyun
--- plugin.php.orig 2005-05-04 11:35:55.000000000 +0900
+++ plugin.php 2005-05-23 02:35:18.000000000 +0900
@@ -36,17 +36,37 @@
return $exist[$name];
}
- if (preg_match('/^\w{1,64}$/', $name) &&
- file_exists(PLUGIN_DIR . $name . '.inc.php')) {
- $exist[$name] = TRUE;
- $count[$name] = 1;
- require_once(PLUGIN_DIR . $name . '.inc.php');
- return TRUE;
- } else {
- $exist[$name] = FALSE;
- $count[$name] = 1;
- return FALSE;
- }
+ if (preg_match('/^\w{1,64}$/', $name) ) {
+ if( file_exists(PLUGIN_EXTRA_DIR . $name . '.inc.php')) {
+ $exist[$name] = TRUE;
+ $count[$name] = 1;
+ require_once(PLUGIN_EXTRA_DIR . $name . '.inc.php');
+ return TRUE;
+ }else if( file_exists(PLUGIN_DIR . $name . '.inc.php')) {
+ $exist[$name] = TRUE;
+ $count[$name] = 1;
+ require_once(PLUGIN_DIR . $name . '.inc.php');
+ return TRUE;
+ }
+ }
+ $exist[$name] = FALSE;
+ $count[$name] = 1;
+ return FALSE;
+
- そういえば、前にプラグインを削除したりして容量を減らしたPukiWikiLightというのがありましたね。*10 -- Ratbeta
- コードをいじらずに済ませる対策としては、ベーシックでないプラグイン(あるいはその逆)のリストをテキストファイルで同梱しておくとか、ベーシックでないプラグインをスパっと削除なりリネームするシェルスクリプトを用意することができると思います。*11 -- henoheno
other: comment (いくつかの設定例をコメントとして付記する)†
// Absolute path of the converter (KAKASI)
$pagereading_kakasi_path = '/usr/local/bin/kakasi';
//$pagereading_kakasi_path = 'c:\kakasi\bin\kakasi.exe';
other: sample (設定済みのサンプル設定ファイルを1～複数添付する)†
other: include / load (設定のデフォルト値を用意しておいて、要所を上書きする小さなファイルと使い分ける)†
- およびがかかったので (^^; わたしは*12 GNU mailmanの設定方法のように、デフォルト値を読み込み(現在のpukiwiki.ini.php)→ユーザ設定値で上書きして(仮にpukiwiki.cfg.php)→それをベースに動くというのがいちばんすばらしいとおもっています。（ユーザーはpukiwiki.cfg.phpだけ新規に作成してそこに設定する）ただ、それを実践するには pukiwiki.ini.php の中にある define が邪魔*13なのですが・・・ -- みこ
- これのメリットはなんといっても、新規の設定が増えてもアップグレードユーザは気にすることがないというのが大きいというのがあります。 -- みこ
- ちなみに、この方法をとっても、初心者に対するケアとして(pukiwiki.cfg.php)のdistは必要ですからね ( -- みこ
- (^^; *14 -- みこ
- official:自作プラグイン/config.inc.phpのようなものを作るときも楽そうですね。 -- teanan
- 私も次はまさにその辺のものを作りたいなーとか勝手に考えてました。 -- okkez
- 参考までに B-Wiki の話をさせて頂きます。B-Wiki の pukiwiki.ini.php の一番下には if(file_exists("sitelocal.ini.php")) require_once("sitelocal.ini.php"); って感じになっていて*15、この sitelocal.ini.php は B-Wiki の管理画面から自動生成するようになっています。中身はPHPのコードで require することでデフォルト値を上書きしています*16。 -- ishii
- pukiwiki-twもpwsetupでconfig.phpを作成し、pukiwiki.ini.phpの末尾でrequireしているみたいですね。 -- にぶんのに
- 実際にもう設定じゃない ini がいっぱいありすぎるので、ちゃんと整理してからでもいいのかも。PKWK_ で始まる定義なんかはほとんどの人が変更する必要ないし*17 -- みこ
- Puki Wiki Farm(自称)も上記に近いことをやっています -- ELF
- ユーザーが触る領域を極力小さくし、アップグレード時のコストやリスクを下げるためにはこのような機構は必須だと思います。RPM/devパッケージを継続して行うためにも必要です。 -- henoheno
- 変数でないと実現できないというモノではないので、特定の実現手法とは混ぜないで下さいね (^^; ＞みこさん。 (設定について)変数か定数かという話題は BugTrack2/29 の上の方にコメントして下さい。 -- henoheno
- 勘違いされているようなのでコメント。（邪魔といっているだけで）変数でないと実現できないといってるつもりはないんですけど・・・ -- みこ
- といいますか、この話題自体がトピック違いなので、少ししたら BugTrack2/29 に移動しましょうか (^^; -- henoheno
- なお定数に関しては if(defined()) を使うことと、デフォルト設定をロードする順番を調整する事でカバーできます。*18 -- henoheno
- サイトの設定は1ファイル(せめて上書きする対象のファイルに1つ)にまとめたいと思いますが、定数と変数が混在する pukiwiki.ini.php, default.ini.phpに対して再定義エラーを回避しながら、上記の方法で実現する方法はあるでしょうか？ -- jjyun
- このあたりは方法論なので結論からいうと実現できます。*19 -- みこ
- コメントありがとうございます。実現は可能だけれども、現状の状態のままだと難しい（実現しようとするとCVSからの差分が大きくなる)のですね。ファイルの一部に手を加えるだけで実現できるなら、すぐ試してみようかなと思ったのですがうまくいきませんで、簡単に実現できる方法を知らないだけかとも思って書き込みしました。 -- jjyun
other: 必要に応じて各自が作ることができるようにする†
- ああ、release.sh などを改造して、「今回のご希望に添ったパッケージを作成できるようにする」、というのはどうでしょう。ELFさんの期待と他の方の期待がバッティングしなくなる気がします。いかがですか。 -- henoheno
- 個人的には選択肢としてあるな気がしますが，多くのWindowsの人はアウトですね． -- ELF
- WindowsでもCygwin使えばいい気がしますけど*20。 -- Ratbeta
- 程度の議論をしても仕方がないですが多くのWindowsの人はcygwin(SFUなど込みで)使わないと思いますということです(笑 -- ELF
- 個人的な需要は無いということで了解です :) -- henoheno
- どこから需要がない話になったか教えていただければと思います -- ELF
- 失礼 (^^; 需要はあるのですね。ということで実装中です。cvs:../devel/release.shは終わりました。release_update.shはrelease.shほどオプション周りをキッチリ作らなかったので、前作業(土台作り)がいりそうです -- henoheno
other: update_XXX.tar.gzの意味合いを変更する†
- 「バージョン間で修正が入っているファイルを抜き出したもの」という意味合いを変更する案。 -- henoheno
- アップグレードの手順を既定し、それに沿ったパッケージを提供する。 -- henoheno
- その前にupdateとupgradeの定義を先にする必要があるのでは? どこかで実は既にされているのでしょうか? -- ELF
- upgrade.tar.gz -> update_XXX.tar.gz です(typoというか、引きずられました) -- henoheno
- ちなみに今一度質問するとupdateのtarballは「誰のため」にあるものでしょうか? 私は「右も左も分からない人(プラグインの追加をすることはあれど改造などしない人)がアップデートするときの助けになるアーカイブ」と考えていましたので，今回の件を挙げました．そういう意味では本当はwikiなどの「コンテンツ」の部分も不要でコアとプラグイン，デフォルトの設定ファイル群*21の集まりであって欲しいと思っていました．少なくともupdate～なファイル名がどちらかというと運用サイトのアップデート用ではないケースは私はあまり知りません． -- ELF
- コアもしくはプラグインの開発者向けならファイルは大きくなりがちかもしれませんが，diff形式でdiff_xxx_to_yyy.tar.gzとかはいかがでしょうか? そのまま運用中のPukiWikiにファイルを上書きなどできないことはメリットの一つ，そのtarball一つで「どこが変わったか」まで分かることが一つ，そしてpatchコマンドが必要ですが現在のupdateのtarballと同様のことも出来ます． -- ELF
コメント†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
