「標準的な配置」の普及これによるツールの簡易化や自動化がすすむ。これまでにそういう文化はなかったのでこの利点が感じられるのは主にこれから作られる・更新されるツールに限定的ではある。†まだサポートor更新がされているものは配布者や有志でやって分散作業することでなんとかなるか。†パッケージマネージャの参照するリポジトリを各配布者のサイトや外部アップローダのURLのみを集めたテキストデータベースとすれば、容量の問題は最小限で防げる。†パッケージ本体以外の付加的情報一般としてdescript.txt的なpackage.txtなどをつけることで示せる。個人的には書きやすくパースしやすいYAML形式がいいな。†ライセンスに関して、とくにシェルを扱う場合、MITやらCCやらの汎用ライセンスではなく個別独自のライセンスが掲げられていることが普通である。この解決策としては、独自ライセンスといっても普通は「仕様化されていないがよくある」ものであるはず。よって「改変可能」や「連絡必須」等の(日本語の)フラグを「CC-BY」みたいなのと同列に扱うことである程度対応できると考える。†インデックス化を集合知に頼る(個人や特定チーム管理だとコストが高い)以上、登録はある程度「勝手に」行われる。ここで作者非作者の扱いについて考察すべきである。†デメリット作者の意思表示を無視して登録される事例が起こりうる(界隈に無視できない程度いるインデックスサイト登録拒否等)。メリットインデックスサイト登録を可とする作者の登録作業が軽減される。作者による更新が停止されたものも扱える。†デメリットすでに更新が停止されたものはほぼ永遠にパッケージ管理で使えないこととなる。インデックスサイト登録を可とする作者の手間が増える/あるいは手間から登録されない事例が多く出る。作者非作者を手間要らずかつ有効に判別するのは困難である(判別手段は作者にとって過度に面倒になりがち)。メリット作者の意思表示に沿わない登録は普通起こり得ない。作者側の大きな利益不利益は作者の意思表示問題であり、ユーザー側の大きな利益不利益は使えるパッケージの多寡の左右である。この「作者の意思表示に反する情報配信が起こりえる」問題はDisc-2、GHOST-TOWN、うわひょ改等のサイトでも同様の問題が現在までも発生しているはず。完成品のゴーストに関してはその一定の解決をみているものであるといえる。このパッケージマネージャはそれと同様のアプローチを、ゴーストを構成するコンポーネントを対象にしてとればいいと思われる。作者は配布サイトに意思表示をすることで、性善説的に意思表示に反する登録を回避している。一方で誤ってかそれに反して登録されてしまった場合、その登録を抹消する仕組みがその保険となっている。既存の登録系サイトと同じような管理体制を敷けば、妥当な運用が出来るのではないか。ここで前述の容量等の問題から、リポジトリは単なるURLリストであり、既存サイトと同様にデータ本体は扱わない環境にある。よってURLリストの禁止や削除を管理すれば既存のサイトと同様の運用が出来る。加えて前述のpackage.txtを参照するという側面から、これの最優先参照先をデータ本体と同一のサイト(一般的に作者の管理下にある)にすれば、登録禁止申請など以前に作者が無意味なpackage.txtやその他の仕様を記述したpackage.txtをおくことで、自動的に意思表示できる。これは検索エンジンに対するrobots.txtのような手軽かつ有効な役割を果たす。このようにpackage.txtの最優先参照先をデータ本体と同一のサイトとして、作者サイトにpackage.txtが存在しない場合には勝手登録のpackage.txtを集めたリポジトリを参照するようにすれば、作者以外の勝手登録を許可しつつ作者の手軽な意思表示を簡単に実現出来る。以上から、以下の仕様を提案する。依存関係をもつものをインストールする場合、基点ディレクトリがないものの扱いをどうするか。依存関係を持つものをアンインストールする場合、依存関係にありかつ他から使われていないものを削除したい場合があるが、他から使われていないという条件の判定をどうするか。上記のような構造のリポジトリである場合、同一パッケージの「古いバージョン」をユーザーが参照することが事実上非常に困難である。package.txtリポジトリの情報であれば一応自動的に古いファイルをバックアップすることは可能であるが、アーカイブは更新されてしまうので結局意味がない。この解決としては、パッケージリポジトリにバージョン情報も付加することによって、同名で違うアーカイブを参照できるようにすることである程度解決できる。作者が古いバージョンをバックアップしない場合は不可能である。この問題の完全な解決にはパッケージリポジトリに過去登録されたパッケージを取得し保存しておくサイトが必要である。package.txtに追加のhistory_archive属性等を設け、拒否を指定すればそれまでの同名パッケージの全てのデータを削除する等で一応対処できる。これはPerlのBackPANにヒントを得たものです。†ネイティブアプリケーションもいいが、まあLL(軽量プログラミング言語)が楽だよね。里々[BSD]ランタイムがGPLライクであっても、ソースの入手先とLICENSEとともにZIPに同梱して配布することが可能?Perl[GPL]よってフォルダの構成が不細工になったりはするが基本的に結構いろんな言語でツール配布は実質問題ない。いくつかのLLではEXEに固めるツールがあったりする。†インストールはアーカイブを単純に展開するだけでも可能なのだが、アンインストールは構成ファイルを把握しておく必要がある。インストール時に解凍したファイルを記録するか、あるいはpackage.txtやその他にリストを書いておくことが必要となる。アップデート時もパッケージ名とバージョンがわからないと話にならない。伺か関連で唯一の似たコンセプトをもつソフト、伺かゴーストマネージャはGUIアプリケーションなのでシェルの見た目情報が出せる。現在のところ伺かのツールは基本的に「サイトに訪れてツールをダウンロードする」というサイクルを暗黙の了解にしている。一方でパッケージマネージャはそれを無視する動線を提供するものとなる。結局現状パッケージマネージャは特に更新停止されたツールに対して十分な情報を与え得ない。ゆえにサイトへの参照等の情報をもつ必要がある。基本的に伺かの開発は「ゴースト制作」。「ゴースト制作」は各ゴーストフォルダに逐一ツールが同梱されていることが前提。Perl云々のパッケージ構成よりはnode.js系の「いろんなところにパッケージがある」形式を前提とすべき。node.jsは「'node_modules'フォルダの下にパッケージ名のフォルダがあってそこにパッケージはあるよ」という方針で、比較的単純なパッケージ管理を実現している。/ghost/master/YAMLで書きやすくパースし易い。nameは日本語も許可する......パッケージマネージャをコマンドラインから使うとき不便かも。place属性は現在いるディレクトリがdescript.txtとかディレクトリ構成とかからゴーストフォルダの中だと判定できた場合に、アーカイブ展開時自動配置する機能。ゴーストのルートフォルダ(ghost/とshell/があるとこ)からの絶対パスを指定して、その下にアーカイブを解凍する。†よくあるコマンドラインのパッケージマネージャはもちろん作るとして、GUI進出はいかにするか。伺かの構成物全般に作用する以上、プログラマ以外への利便性も考えたい。上記LLでGUIを構成できるのは知ってるうちで以下の通り。†node-webkitというWebブラウザベースのGUIがネイティブで作れるものがある。HTML/CSS/JavaScript?で完全に構成できる。基本的に現在配っているアーカイブに変更の必要なく、新規に構成情報を書いたpackage.txtをおくだけで、なんとかなる、という仕組みを作りたいという方向性。「それぞれのフォルダでパッケージ管理する」とこあたりはnpmとかが参考になると思います。用語リポジトリ「倉庫」。何らかのデータが整理されておかれている場所の総称。ここでは「データベース」や「ZIP置き場」を指す。アーカイブZIPとかEXEとか、要は配布するツールの本体。伺かパッケージマネージャで扱われるパッケージは「パッケージ名」と「パッケージのアーカイブの場所」を最も基本的な情報として扱われる。「パッケージ名」と「パッケージのアーカイブの場所」を対応付けるリポジトリ。†パッケージ名、パッケージの保持バージョン、パッケージのアーカイブの場所の情報を持ったYAMLである。)で表されるリポジトリである。参照パッケージマネージャはまず最初にこのリポジトリを参照し、「パッケージ名」、「パッケージの保持バージョン」と「パッケージのアーカイブの場所」の対応リストを得る。次に「パッケージのアーカイブの場所」からアーカイブリポジトリを参照する。変更リポジトリは可能な任意のユーザーが変更可能である。このリポジトリには「パッケージ名」、「パッケージの保持バージョン」と「パッケージのアーカイブの場所」のみを登録可能であるべきである。このような単純な構成のリポジトリは、CGI等のプログラムを必要とせず、単にファイルを配置するだけで構成可能である。†リポジトリとしては検索機能等は提供しない。それらは本質的でない。パッケージマネージャ上や他の場所で提供できるし、されるべきである。「アーカイブ」と「package.txt」をもつリポジトリ。これは通常「アーカイブ」の作者サイトか作者が制御できるファイル置き場である。「アーカイブ」と「package.txt」が同一のディレクトリに配置されているか、「アーカイブ」のみが存在する。「package.txt」はアーカイブ名に「.package.txt」をつけた名前「(アーカイブ名).package.txt」である。「パッケージ名」に対応した「パッケージのアーカイブの場所」に存在するリポジトリである。参照パッケージマネージャは2番目にこのリポジトリを参照し、「package.txt」を得るか、「package.txt」が存在しないことを検知する。正常な「package.txt」が存在する場合、「アーカイブ」がダウンロードされ、リポジトリの参照はここで終了する。不正な「package.txt」が存在する場合、処理は失敗し、リポジトリの参照はここで終了する。「package.txt」が存在しない場合、「パッケージ名」からpackage.txtリポジトリを参照する。通常「アーカイブ」の作者のみが情報を変更できる。特筆すると、「アーカイブ」をパッケージマネージャから利用できなくするために不正な「package.txt」をおくことは違反ではない。「パッケージ名」と「package.txt」を対応付けるリポジトリ。「パッケージ名」に対応した「package.txt」が配置されている。)で表されるリポジトリである。参照パッケージマネージャは必要な場合最後にこのリポジトリを参照し、「package.txt」を得るか、「package.txt」が存在しないことを検知し、リポジトリの参照を終了する。正常な「package.txt」が存在する場合、アーカイブリポジトリから「アーカイブ」がダウンロードされる。それ以外の場合、処理は失敗する。変更リポジトリは可能な任意のユーザーが変更可能である。このリポジトリには「パッケージ名」と「package.txt」のみを登録可能であるべきである。†リポジトリとしては検索機能等は提供しない。それらは本質的でない。パッケージマネージャ上や他の場所で提供できるし、されるべきである。このような単純な構成のリポジトリは、CGI等のプログラムを必要とせず、単にファイルを配置するだけで構成可能である。通常ZIPファイルである。ZIP以外の場合それを解凍・配置するスクリプトが必要となる。†パッケージの情報をYAML形式で書いたファイル。UTF-8が普及しているのでUTF-8を使用する。