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 2005-03-18 (金) 00:27:57
  • update_XXX.tar.gz は以前から手作業で用意されてきたものであり、ニーズが読めないものであったため、PukiWiki 1.4.4のリリース当初はリリースするつもりがありませんでしたが、official:PukiWiki/Dounload/1.4.4 での要望を受けて用意したものです。 -- henoheno 2005-03-20 (日) 19:55:08
    • update_XXX.tar.gz は現在 cvs:../devel/release_update.sh によって自動的に生成できるようになっています。このスクリプトは任意のcvsタグ間の修正をチェックし、変更が無かったものを削除します(結構時間がかかります)。 -- henoheno 2005-03-20 (日) 20:09:06

コメント

  • CVS環境があるなら自動でマージしたり手動で修正できたりするのでなにかと便利ですのでお勧めです。 -- Ratbeta? 2005-03-16 (水) 16:37:41
  • それ*1はそうだと思いますが、ELFさんはそういうことを言ってるんじゃないと思います。フェイルセーフというかフールプルーフというか、イージーミスを起こしにくくさせる気配りが欲しいということなんだと思います。 -- okkez 2005-03-16 (水) 21:50:52
  • 通常、同じファイルを pukiwiki.ini.php 以外のファイル名で提供するとかの感じですよね。わたしのところではそうしています。 -- みこ 2005-03-16 (水) 22:37:09
  • 質問の意図は理解していましたけれども。要するにphpのphp.ini-distみたいなあれですよね?それだとCVS環境での同期が取りにくくなる問題が出てくるんじゃないかと思います。upgradeのみなら問題はないと思いますけれども。 -- Ratbeta? 2005-03-17 (木) 10:43:15
  • そう、それですよ<php.ini-dist.php。でも、CVS上ではpukiwiki.ini.phpのままでrelease.shでパッケージングするときにリネームすれば済む話だと思いました*2。 -- okkez 2005-03-17 (木) 22:54:55
    • そういう話.CVSはある意味一旦どうでもいいんですが,tarballで設定ファイルを上書きの危険性は可能な限り避けられる方が好ましいと考えます.例えばwikiディレクトリとかはpukiwiki.ini.phpで別のディレクトリ名にしたら間違って上書き!!ってのから逃げられるんですが,pukiwiki.ini.phpなどの*.ini.phpはコアをハックしなければそうはいきません*3 -- ELF 2005-03-18 (金) 00:24:44
    • うーん、そこまで「tarball を展開して上書き」という運用を推奨されたいのですか・・・ (^^; -- henoheno 2005-03-18 (金) 00:31:31
  • お疲れ様です。それぞれのページに、現状の分析(最初は仮定でいいじゃないですか)と期待されるモノとをそれぞれ整理しながら進めて下さいませんか (^^; -- henoheno 2005-03-18 (金) 00:27:33
  • さて、moveかcopyかという話みたいですね。 -- henoheno 2005-03-18 (金) 00:27:47

move (設定ファイルをうっかり上書きしない様にどけておくのはどうか)

  • 現状の update_XXX.tar.gz は「バージョン間で修正が入っているファイルを抜き出したもの」で、それ以外のものではありません。 -- henoheno 2005-03-18 (金) 00:27:57
    • これに対しELFさんは何か特定の運用を期待されている様ですね。上に書いた通りで update_XXX.tar.gz は「各自が実運用しているPukiWikiに上書き展開しろ」と言う代物ではないのです。「move して pukiwiki.ini.php というファイルを無くせ」という提案は、現段階では特定の活用事例のみに根ざしたものであるように見受けられます。 -- henoheno 2005-03-18 (金) 00:28:05
      • っていうかふつー「update_XXX.tar.gzってアップデート用アーカイブ」って思いませんか? 上記のような目的ならかなり強く別名にすることを提案します -- ELF 2005-03-19 (土) 13:45:03
      • 単にファイルの差分を見たいなら技術的には旧tarballと新tarballの差分を取り出せばいいだけです*4.仮に「差分を確認したい」と「アップデートを簡単にしたい」の活用事例があったとして,どちらの方が比重は高いと思いますか?
    • また、通常のパッケージに対しmoveを適用した場合、PukiWikiの設置にあたって一手間かかることになってしまいます。具体的には「入手して展開して即動く」という大きな利点が失われるのですが、それについてどうお考えですか。 -- henoheno 2005-03-18 (金) 00:28:14
  • そもそもupdate_XXX.tar.gzを使っての更新はサポート対象外のような気がします。単純にファイルがちぐはぐになったりする可能性もありますし、そうでなくても動作に問題が出る可能性があります。 -- Ratbeta? 2005-03-18 (金) 11:56:02
    • BugTrack2/12のELF的感覚の用語をあえて使うとして,その前提だと「アップデート」は殆どの場合,上書きのみで済むはずです.すまないものは「アップグレード」で仕様が変わっているから.まぁ当然100%な話ではないですが(苦笑 また,PukiWikiは現在「アップグレード」のものはリリースされても「アップデート」のものはあまりリリースされないので当然問題が出てくる可能性は非常に高いです. -- ELF 2005-03-19 (土) 13:54:27
    • うーむ、現在の update_XXX.tar.gz を既存のPukiWikiに重ねがけ(上書き)して、それで「アップデート」/「アップグレード」が成功するはず、とされる主張は、update_XXX.tar.gz が何であるかに対する誤解と、運用方法に関する仮定に根ざしていらっしゃるように思います。tar.gzの中身でいきなりファイル単位に上書きしてしまうような(乱暴な)運用は、「仕様が変わっていなければ成功する」とか、「あるレベルの仕様変更で失敗する」などというモノではありませんので、仕様変更の有無や規模に関する主張とは全く関係が無い様に思います。 -- henoheno 2005-03-20 (日) 00:02:24
    • なお、update_XXX.tar.gz の「update」という名前が誤解を与えるかというと、そんな事は無いでしょう。普通は「これはどういうものか」を知ろうとしますから、「1.4.4と1.4.5_1の間で修正/追加されたファイルのみ」といった説明を見てその意味を理解されるでしょう。 -- henoheno 2005-03-20 (日) 00:06:32
      • SourceForgeから入ってPukiWikiプロジェクトのページに行き,Downloadからダウンロードしようとした人はどうやってその情報を知ることができるのでしょうか? -- ELF 2005-03-21 (月) 15:14:16
      • そのルートからファイルを見た人にとっては、ファイルが何者であるのかは現状ノーヒントです。これに対する提案であれば、まずはヒントを掲載する(ファイルの中か、ファイルリリースの説明の部分に)という対策が取れるでしょう。なお、注意深い方なら、展開したパッケージの中身を見たり、orgサイトを見たりするでしょう。「ノーヒントのパッケージを勝手に判断していきなり上書き展開する」方に必要なのは誤解を生まない情報や、ほんの少しの注意深さです。設定ファイルをどけておく事ではありません。 -- henoheno 2005-03-21 (月) 19:54:45
  • 「1.4.4と1.4.5_1の間で修正/追加されたファイルのみ」という表現からは、ELFさんの仰るように「じゃあこのファイルだけ上書きすればアップデート完了だな」と思うユーザがいてもおかしくないと思います。定義なりファイル名なりを変えるおつもりがないのならば、それこそユーザに「誤解」させないように「これをそのまま上書きしてアップデートはしないでください」とでも明記しておくべきかと思われます。 -- sagen 2005-03-20 (日) 13:26:27
  • 「安直な」ファイル単位の上書き行為 がなぜ良くないのかは、影響範囲を明確にすれば明らかです。同じ名称のファイルは全てリセットされ、移動されていた場合の古いファイルは消されずに残り、カスタマイズを行ったコードがあった場合は結果的に予測できない不整合が発生する可能性があります。 -- henoheno 2005-03-20 (日) 19:45:47
    • 設定ファイルの類 (少なくともadminpassはリセットされる)
    • wiki/ 以下 (所定のデフォルト文書と同名のページがリセットされる。PukiWiki 1.4.5 における「プラグインマニュアル」のように、文書名の変更があれば、だぶる)
    • cache/ 以下 (リセットされる/現状と相違が出る)
    • .htaccess (リセットされる)
    • plugin/ 以下 (削除したはずのプラグインが再び配置される可能性がある/カスタマイズがリセットされる)
    • lib/ 以下 (行ったはずのカスタマイズが打ち消される可能性がある/カスタマイズが中途半端に残り、致命的な不整合が生じることがある)
  • 自分が何をやっているのかが解っている方や、慎重な方には全く問題にならないでしょうから、「上書きするな」と明記するのはまた別の意味で正しくないでしょう> sagenさん -- henoheno 2005-03-20 (日) 22:17:47
    • 「安全側に傾ける」という意味では「上書きするなorしない方が良いよ」というのは正しいのではないでしょうか? -- okkez 2005-03-21 (月) 17:36:13
    • 一言では今回のように勘違いに根ざした問題の歯止めにはならないと思いますので、update_XXX.tar.gz に関する説明書きがもう少しあると良いのでしょうね。(このBugTrackがそうなるかも) -- henoheno 2005-03-21 (月) 19:46:59
    • 「自分が何をやっているのかが解っている方や、慎重な方」以外の人≒初心者の為に、せめて注意書きを書いてはどうかと提案したのですが……。(^^; -- sagen 2005-03-22 (火) 11:51:31
  • update_XXX.tar.gz がどのようなものかは上にまとめた通りで、どう料理する(どのような手順で利用する)かは各人次第です。情報が足りないというのであれば補いましょう。しかし今ある道具の存在に納得されないのはなぜですか? 特定の運用を過程した変更を加えた場合、かえって問題となる運用が存在するかもしれない可能性を考慮されないのはなぜですか? また、希望に添った新しい道具を作ろうとか、その実現可能性について話を進められないのはなぜですか? 現状をふまえずに誤解に基づいた提案を突き進める前に、今一度ご検討をお願いします。 -- henoheno 2005-03-21 (月) 19:58:30
    • update_XXX.tar.gz は私が参加する前からこのような内容であったものなので、誤解なきよう。 -- henoheno 2005-03-21 (月) 20:00:52
      • 今ある道具の存在に納得するというか「現状のものまずいんじゃないの?」の指摘であって,現状のものは「常に納得しなければならない」なら当然バグと新規機能要求などを除いた「改善要求は何もいらないわけです」で,そういった考えははあるのでしょうか?(ないはずと思っていますが)また,別の方向性への「提案」なので当然現在の方向性がっちりで使っていればいるほど問題が出る可能性はあるでしょう.そして,「まったく問題がない」のであれば私以外に「問題があるのでは」と考える人は居なかったはずだと思いますが,現実は程度の違いはあれど問題視している人は少なからず居ることは事実だと思います -- ELF 2005-03-22 (火) 03:56:12
      • updateのtarballができたときになぜ指摘しなかったか? というと,そもそもpukiwiki.orgのダウンロードはいつも迷子になるので使わずにsf.jpからのダウンロードばかりしていました*5,sf.jpのファイル情報は以前*6までファイルライブラリとしてのコンテンツはほとんどなく*7特にプロジェクトトップページからはupdateのtarballは出てこなかったので単に「知らなかった・認識していなかった」だけです.henohenoふぁんにファイル管理を編集していただいたこともあり,着目しようとして今回問題があるのでは? と考えたわけです.つまり最初から知ってたら最初から言ってるわけです. -- ELF 2005-03-22 (火) 04:00:53

copy (設定ファイルの控えを残しておくのはどうか)

  • みこさんの実践されている、pukiwiki.ini.php の copy を pukiwiki.ini-dist.php という名前で残すというアイデアはそれなりに有効(親切)だと思います。実際に多くのサーバー系ソフトウェアがそうしていますよね。 -- henoheno 2005-03-18 (金) 00:28:25
    • PukiWikiの場合 copy について考慮すべきは、既存のパッケージサイズとiniファイルのサイズ(や構成)、そして実際の活用状況をふまえたバランスになると思います。PukiWikiは展開すれば(一部圧縮していますが)1.2MB程度にもなり、例えば10MBしか使えないWebホスティング環境では結構な重荷です。そこに全部合わせて40KB*8の *.ini-dist.php を余計に置きたいのかどうか。またPukiWikiのパッケージは小さく、素早く入手でき素早く解凍できます。なのに *.ini-dist.php を含める意義が本当にあるのかどうか。このあたりについて皆さんどうお考えですか。 -- henoheno 2005-03-18 (金) 00:28:33
      • それは、大局をみてなさすぎ。そういうひとはdistを消すなどの工夫をするので no problemですよ (^-^ -- みこ 2005-03-18 (金) 01:06:17
      • ファイルの頭なり、インストールマニュアルなりに一言「邪魔なら消しても問題ないよ」って書いておけばいいと思います。 -- okkez 2005-03-18 (金) 02:28:08

other: プラグインを二分する

  • 容量の問題で言うとプラグインの重要度を整理して基本プラグインと拡張? プラグイン的2段階で配布をするほうがいいのではないかと思います*9. -- ELF 2005-03-19 (土) 13:46:45
    • 分けるなら、さらにPLUGIN_DIR を PLUGIN_DIRS という形で設定できると、サイト共有のもの/サイト個別に要求される拡張プラグインの格納場所と使い分けることができて嬉しいと思うのですが、どうでしょう? -- jjyun 2005-03-20 (日) 08:51:34
    • 標準添付プラグインと自作プラグインのディレクトリを分けるような使い方もできますね。 -- teanan 2005-03-20 (日) 10:03:25
    • プラグインのロード速度に影響しない範囲でお願いしたいですね。 -- Ratbeta? 2005-03-20 (日) 18:48:14
  • 脱線気味ですが (^^; 容量の問題にかかわらず、基本プラグインとそうでないものを簡単に分けることができることは良いことだと思います。ベーシックなプラグイン以外のもの(例えばtouchgraphとか)をスパッと削除して、ベーシックな機能しか動作しないPukiWikiがすぐに用意できる状態であれば良いですよね。。 -- henoheno 2005-03-20 (日) 22:23:44
    • PukiWiki 1.3のころはpluginディレクトリの中をスパッと削除しても(newpageを除き)問題なかったのですが、1.4では基本機能もpluginの形に落として単純化されているため、現状のようになっているようです。(当時の名残として、今も cmd=read, cmd=edit という基本機能の呼び出し方法が残っています) -- henoheno 2005-03-20 (日) 22:27:43
    • 現在プラグインのロードは、全てが特定(同一)のディレクトリにあるものとして作られていますので、「pluginディレクトリの中に無かったら、次にここを探す」という機構を追加すれば実現はできそうですね。 -- henoheno 2005-03-20 (日) 22:32:25
      • こんな感じでしょうか? (ロード速度に影響しないかどうか心配ではありますが...) -- jjyun 2005-05-23 (月) 03:01:59
        --- 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? 2005-03-20 (日) 23:00:29
    • コードをいじらずに済ませる対策としては、ベーシックでないプラグイン(あるいはその逆)のリストをテキストファイルで同梱しておくとか、ベーシックでないプラグインをスパっと削除なりリネームするシェルスクリプトを用意することができると思います。*11 -- henoheno 2005-03-20 (日) 23:19:13
  • 続編: BugTrack2/242 (デフォルトで有効にする)標準添付プラグインの見直し

other: comment (いくつかの設定例をコメントとして付記する)

// Absolute path of the converter (KAKASI)
$pagereading_kakasi_path = '/usr/local/bin/kakasi';
//$pagereading_kakasi_path = 'c:\kakasi\bin\kakasi.exe';
  • 現在のPukiWikiではこの方法が良く使われています -- henoheno 2005-03-19 (土) 19:47:29

other: sample (設定済みのサンプル設定ファイルを1~複数添付する)

other: include / load (設定のデフォルト値を用意しておいて、要所を上書きする小さなファイルと使い分ける)

  • およびがかかったので (^^; わたしは*12 GNU mailman設定方法のように、デフォルト値を読み込み(現在のpukiwiki.ini.php)→ユーザ設定値で上書きして(仮にpukiwiki.cfg.php)→それをベースに動くというのがいちばんすばらしいとおもっています。(ユーザーはpukiwiki.cfg.phpだけ新規に作成してそこに設定する)ただ、それを実践するには pukiwiki.ini.php の中にある define が邪魔*13なのですが・・・ -- みこ 2005-03-18 (金) 00:48:51
    • これのメリットはなんといっても、新規の設定が増えてもアップグレードユーザは気にすることがないというのが大きいというのがあります。 -- みこ 2005-03-18 (金) 01:00:32
    • ちなみに、この方法をとっても、初心者に対するケアとして(pukiwiki.cfg.php)のdistは必要ですからね ( -- みこ 2005-03-18 (金) 01:04:01
  • (^^; *14 -- みこ 2005-03-18 (金) 00:55:01
  • official:自作プラグイン/config.inc.phpのようなものを作るときも楽そうですね。 -- teanan 2005-03-18 (金) 01:31:54
  • 私も次はまさにその辺のものを作りたいなーとか勝手に考えてました。 -- okkez 2005-03-18 (金) 02:26:00
  • 参考までに 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 2005-03-18 (金) 02:28:35
    • pukiwiki-twもpwsetupでconfig.phpを作成し、pukiwiki.ini.phpの末尾でrequireしているみたいですね。 -- にぶんのに 2005-03-18 (金) 04:46:38
  • 実際にもう設定じゃない ini がいっぱいありすぎるので、ちゃんと整理してからでもいいのかも。PKWK_ で始まる定義なんかはほとんどの人が変更する必要ないし*17 -- みこ 2005-03-19 (土) 09:44:47
    • 設定項目を見直すといえばBugTrack2/29ですね…。 -- Ratbeta? 2005-03-19 (土) 10:39:49
  • Puki Wiki Farm(自称)も上記に近いことをやっています -- ELF 2005-03-19 (土) 13:51:03
  • ユーザーが触る領域を極力小さくし、アップグレード時のコストやリスクを下げるためにはこのような機構は必須だと思います。RPM/devパッケージを継続して行うためにも必要です。 -- henoheno 2005-03-19 (土) 19:55:10
    • 変数でないと実現できないというモノではないので、特定の実現手法とは混ぜないで下さいね (^^; >みこさん。 (設定について)変数か定数かという話題は BugTrack2/29 の上の方にコメントして下さい。 -- henoheno 2005-03-19 (土) 19:58:19
      • 勘違いされているようなのでコメント。(邪魔といっているだけで)変数でないと実現できないといってるつもりはないんですけど・・・ -- みこ 2005-03-20 (日) 10:32:01
    • といいますか、この話題自体がトピック違いなので、少ししたら BugTrack2/29 に移動しましょうか (^^; -- henoheno 2005-03-19 (土) 20:00:06
  • なお定数に関しては if(defined()) を使うことと、デフォルト設定をロードする順番を調整する事でカバーできます。*18 -- henoheno 2005-03-19 (土) 20:05:35
    • サイトの設定は1ファイル(せめて上書きする対象のファイルに1つ)にまとめたいと思いますが、定数と変数が混在する pukiwiki.ini.php, default.ini.phpに対して再定義エラーを回避しながら、上記の方法で実現する方法はあるでしょうか? -- jjyun 2005-03-20 (日) 09:08:59
      • このあたりは方法論なので結論からいうと実現できます。*19 -- みこ 2005-03-20 (日) 10:35:14
      • コメントありがとうございます。実現は可能だけれども、現状の状態のままだと難しい(実現しようとするとCVSからの差分が大きくなる)のですね。ファイルの一部に手を加えるだけで実現できるなら、すぐ試してみようかなと思ったのですがうまくいきませんで、簡単に実現できる方法を知らないだけかとも思って書き込みしました。 -- jjyun 2005-03-21 (月) 07:46:14

other: 必要に応じて各自が作ることができるようにする

  • ああ、release.sh などを改造して、「今回のご希望に添ったパッケージを作成できるようにする」、というのはどうでしょう。ELFさんの期待と他の方の期待がバッティングしなくなる気がします。いかがですか。 -- henoheno 2005-03-18 (金) 00:36:53
  • 個人的には選択肢としてあるな気がしますが,多くのWindowsの人はアウトですね. -- ELF 2005-03-19 (土) 13:56:57
    • WindowsでもCygwin使えばいい気がしますけど*20。 -- Ratbeta? 2005-03-19 (土) 16:42:09
      • 程度の議論をしても仕方がないですが多くのWindowsの人はcygwin(SFUなど込みで)使わないと思いますということです(笑 -- ELF 2005-03-21 (月) 15:11:05
    • 個人的な需要は無いということで了解です :) -- henoheno 2005-03-20 (日) 00:01:57
    • どこから需要がない話になったか教えていただければと思います -- ELF 2005-03-21 (月) 15:11:56
  • 失礼 (^^; 需要はあるのですね。ということで実装中です。cvs:../devel/release.shは終わりました。release_update.shはrelease.shほどオプション周りをキッチリ作らなかったので、前作業(土台作り)がいりそうです -- henoheno 2005-03-21 (月) 21:06:47
    • cvs:../release_update.sh も完了。興味のある方はお試しください。バグ/成功リポートと高速化案(パッチ)募集中! -- henoheno 2005-03-21 (月) 22:48:03

other: update_XXX.tar.gzの意味合いを変更する

  • 「バージョン間で修正が入っているファイルを抜き出したもの」という意味合いを変更する案。 -- henoheno 2005-03-19 (土) 10:48:11
  • アップグレードの手順を既定し、それに沿ったパッケージを提供する。 -- henoheno 2005-03-19 (土) 10:50:16
    • その前にupdateとupgradeの定義を先にする必要があるのでは? どこかで実は既にされているのでしょうか? -- ELF 2005-03-19 (土) 13:57:43
    • upgrade.tar.gz -> update_XXX.tar.gz です(typoというか、引きずられました) -- henoheno 2005-03-19 (土) 16:05:24
  • ちなみに今一度質問するとupdateのtarballは「誰のため」にあるものでしょうか? 私は「右も左も分からない人(プラグインの追加をすることはあれど改造などしない人)がアップデートするときの助けになるアーカイブ」と考えていましたので,今回の件を挙げました.そういう意味では本当はwikiなどの「コンテンツ」の部分も不要でコアとプラグイン,デフォルトの設定ファイル群*21の集まりであって欲しいと思っていました.少なくともupdate~なファイル名がどちらかというと運用サイトのアップデート用ではないケースは私はあまり知りません. -- ELF 2005-03-22 (火) 04:07:43
    • コアもしくはプラグインの開発者向けならファイルは大きくなりがちかもしれませんが,diff形式でdiff_xxx_to_yyy.tar.gzとかはいかがでしょうか? そのまま運用中のPukiWikiにファイルを上書きなどできないことはメリットの一つ,そのtarball一つで「どこが変わったか」まで分かることが一つ,そしてpatchコマンドが必要ですが現在のupdateのtarballと同様のことも出来ます. -- ELF 2005-03-22 (火) 04:12:14

コメント


*1 CVSやらSubversionやらを使うことで管理を楽にできること
*2 簡単ですよね?
*3 厳密には*.lngとかもそうですが
*4 しかもそういう差分を知りたい人はさらに「ファイルの中のどこが変更されたか」という情報まで欲しい人が多いのではないかと推測します
*5 クリックしまくってたらダウンロードできるようになったってのがpukiwiki.org経由だといつものパターン
*6 henohenoさんに編集していただくまで
*7 upgradeのtarballあったのかな
*8 みんな他の*.ini.phpを忘れてるでしょ・・・ (^^;
*9 分別作業がとても大変なのは推測できますが
*10 完全に余談ですsoz
*11 PukiWikiLightは維持することを考慮されていないようでしたので、過去形になってしまうのは仕方ないと思います・・・ (^^;
*12 これは随分前からここ(dev)でいってるけど
*13 PHP の define は undef できないので変数の方が使い勝手がいい
*14 もう何度も提唱しているのでこれで解決されなければ独自でやりまする(T-T
*15 実際のファイル名はチョット違う。
*16 参考になりませんか、そうですか… orz
*17 必要なのは開発者ぐらいでは?
*18 B-Wiki楽しそうだなぁ・・・
*19 一例として、iniの時は変数にして、iniを読み終わった後にdefine定義して変数を消す・・・とかね(^-^
*20 それ以外の多くの人という意味だったのかも(^^;
*21 悩ましいところですが設定ファイル群は単純に上書きなだけなら要らないかも

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2005-05-23 (月) 03:08:32
Site admin: PukiWiki Development Team

PukiWiki 1.5.2+ © 2001-2019 PukiWiki Development Team. Powered by PHP 5.6.40-0+deb8u7. HTML convert time: 0.387 sec.

OSDN