当ブログの記事は(特に公開直後は)頻繁に改定される場合があることをご了承ください。ようなツールになっていくのだろうと思います。月の正式リリースを目指しているようです。ロードマップも公開されています。マネージャーに求められているものについて、考えていこうと思います。等のツールがどう対処しているかというようなことについてはよく知りません。他には以下のようなものがあります。環境のように、目的特化で長期間使うことを想定しなくてよい場合にはいいかもしれないと思っています。「アプリのインストールに管理者権限を必要としない」というのがひとつのテーマみたいですね。それも良し悪しかな、と思います。トラブルがあったと聞いて、初めて知りました。使ったことがありません。マネージャーと言えるだろうと思います。最終的に何を目指しているのか、よくわかっていないところは多いのですが、とりあえず以降の記事で必要な点に絞って、現状を簡単に紹介しましょう。一般的な解説は他のサイトを見てください。インストールできるアプリケーションは、それに対応するマニフェストというものを公開します。リポジトリで公開されています。パッケージをダウンロードしてきて実行するというだけのものです。マニフェストは、そのアプリケーションの開発元だけでなく、第三者が書いて、公開することが可能です。バイナリで配布することが多いのではないかと思います。基本的には、どこか別のサイトからインストーラーや配布パッケージをダウンロードしてきて展開するという形態が多いようです。これらのインストーラーは、単にアプリケーションのファイルを配置するのみならず、それが動作するための諸々の環境整備をも、その責務として含みます。その中には、必要な依存関係の解決も含まれます。フレームワークをインストールしておく必要がなくなり、動作環境を整えるハードルがぐっと下がりました。マネージャーが、アプリケーションが動作するために必要な依存関係を解決するということに、あまり馴染みがないような気がします。依存関係のインストールをサポートしています。マネージャー(とでも言うのでしょうか)でも、依存関係の解決をサポートしています。いうと、未だどういう形になるかはまったく未知数ながら、アプリケーションの依存関係をサポートするということが、一応は表明されています。個人的に、最も注目している問題が、この依存関係のサポートです。いうのも、これをサポートするかしないかは、パッケージマネージャーの在り方にとてつもなく大きな影響を与えるだろうと考えるためです。インストール依存関係のサポートが、なぜそんなに大きな問題を引き起こすのか。インストールを実現する必要があるからです。例を挙げて説明しましょう。インストールしようとしています。インストールされます。リリースされています。間には互換性がありません。併存できなければなりません。機能しなくなってしまうからです。共存を許しているものは多くないのではないでしょうか。アンインストール(アップグレード)されてしまうでしょう。問題ではなく、アプリケーションの問題なので、ここで論じても仕方がないことですが。(アプリケーションが対応しているならば)同じアプリケーションの複数のバージョンが同時にインストールされているという状況をサポートしなければならないわけです。2.0、どちらを実行すればよいでしょうか。実行することでしょう。実行されなければ困ってしまいます。マネージャーによってインストールされたアプリケーションは、その場所をいちいち意識しなくてよいように、自動的にパスが通った場所に配置されます。アプリケーションでも、これは同じです。どのように作られているでしょうか。パスの通ったところに存在することを前提にしているかもしれません。実行することができるかもしれません。実装することを要求することになってしまい、現実的ではない気がします。環境変数をセットするなどということができればいいのかもしれませんが。場合は、依存モジュールを探索するルールを設けることで対処しているようですね。マネージャーの例に漏れず、インストールしたアプリケーションを更新するコマンドの実装も予定されています。インストールが問題になります。更新することがあってはならないということです。動かなくなってしまうからです。やり方はいろいろ考えられます。更新しないというのが一案。互換性のあるバージョンを宣言するというのが一案。までは安全にアップデートできるということになります。プラグインはこのような機能を持ちます。いずれの場合であっても、新しいバージョンがあるのに、敢えてアップデートしないということは、セキュリティ上のリスク等を抱え込む可能性があります。そのような場合には、ユーザーに何らかの注意を促す仕組みがあってもよいかもしれませんね。これは依存関係に関係なく有用であろうと思います。バージョン番号が変わっていれば、以前のバージョンと互換性がなくなっている(部分がある)ということを意味するというものです。すべてのアプリケーションが、この仕様に従ってバージョニングされているとは限りません。なっただけで、互換性がなくなるアプリケーションがあるかもしれません。従ってバージョニングされるべきという提案もあります。従ってバージョニングすればよいという意見もありますが、二系統のまったく関係ないバージョン番号が存在することになるので、ユーザーを混乱させることになるだけだと思います。自動更新機能を持つアプリケーションアプリケーション自体が自動更新機能を持っている場合があります。アプリケーションのインストールもサポートする予定なので、それが代表例ということになるでしょう。検知できなければ、問題が起きる可能性があります。別のパッケージから依存されているアプリケーションが、それ自体の機能によってアップデートされてしまうことによって、互換性が破壊されるという懸念も考えられるかもしれません。冒頭で紹介したように、リポジトリにあるのはマニフェストだけで、インストーラーは別のサイトからダウンロードする構造を取っています。このような仕組みは、パッケージの依存関係を実現する上で、大きな障害になり得ます。インストーラーがいつまでもサイトに残っているだろうか、ということです。リスクでもあればなおのことです。公開されていない、ということがあり得るからです。このような事態を防ぐために、一度公開したパッケージの削除は原則的にサポートしていません。特定のバージョンを非表示にするということは可能ですが、これは新規にインストールする場合の検索に出てこなくなるというだけであり、過去に公開されていたバージョン番号を知っていれば、ダウンロードすることは可能です。これは、そのバージョンに依存している別のパッケージが壊れないようにするためです。過去に公開されたパッケージの完全な削除を許容してしまうと、他の悪意あるパッケージが、その名前を乗っ取る可能性があるという問題もあります。このような保持ポリシーが必要であろうと思います。パッケージ自体をリポジトリでホストしなければなりません。現在のように、リポジトリ運営者の監督下にないサーバーからダウンロードしてくることしかできない仕様では、このような保持ポリシーは実現できません。公開すべきであると考えます。問題を引き起こしたことがあります。いうモジュールが、作者の意向によって公開停止になったことにより、それに(直接的/間接的に)依存する数千ものライブラリが壊れてしまったというものです。含まれていたことなどもあって、非常に大きな混乱をもたらしました。よって買収されています。よって運営されているわけです。運営しているものです。リポジトリの運営にあたっても、賢明な判断を下してくれるであろうと期待したいところです。著作権問題と普及のジレンマしかし、このような保持ポリシーを持つリポジトリの実現の障害として、以下のような問題があります。リポジトリでホストさせることは、インストーラーを第三者が外部サイトに勝手に転載させることになり、著作権侵害になり得るということです。いって、どちらかを諦めるという選択肢はありません。普及にとって大きな障害となるからです。マネージャーとしては、是非とも達成しなければならない要件です。抱え込んでしまえばよいですね。すれば、この章で長々と言ってきたような問題はすべて解消されます。少々ディスク容量は食いますが。パッケージの信頼性あるパッケージをインストールすべきか否か、そのパッケージは信頼できるのか、どのように判断したらよいでしょうか。最終的には利用者の自己責任に帰します。ブラウザ経由でアプリケーションの公式サイトからダウンロードした場合と同じです。マネージャーという間接層が入ることによって、無用な心配事を増やすべきではありません。アプリケーション作者以外がマニフェストを作ることが一般的です。そのようなマニフェストを、どうすれば信頼できるでしょうか。最初はひとまず、インストーラーのダウンロード元が信頼できるサイトかどうかで判断できるかもしれません。マニフェスト作者に悪意があれば、新しいバージョンであると称して、全く関係のないインストーラーにすり替えることができるかもしれません。確認するような煩雑な運用では、使い物になりません。上でプルリクエストを出す必要があります。このプルリクエストは、自動的に処理され、一定の審査を経て公開されるようですが、審査の詳細は公表されていません。あるマニフェストのあるバージョンと、その後継と目されるバージョンが、本当に同一の作者によるものかという問題もあります。アカウントごとリネームされてしまえば、他者がパッケージ名を乗っ取ることも可能かもしれません。マニフェスト自体に何らかのデジタル署名を施すことによって、作者の身元や、バージョンの継続性を担保できるべきなのではないかとも思います。いわゆるコード署名証明書は非常に高価であり、個人開発者が取得するのは困難です。何かもっと安価な方法がないでしょうか。パッケージが、元のソフトウェア作者か、または、信頼できるコミュニティによって保守されていることを、人力で確認する仕組みのようです。やって検証しているのかよくわかりませんが。個人的には、同じアプリケーションに対して、その作者が公開しているマニフェストと、第三者が公開しているマニフェストがあったら、作者が公開している方を使いたいという気になります。場合によっては、マニフェストが、作者がサポートしていないような方法でアプリケーションをインストールするように作られているかもしれません。そのような場合も含め、作者が何らかの異議申し立てをできる仕組みが必要かもしれません。ディレクトリ下にインストールするというポリシーを持っているからです。アプリケーションであれば可能です)が、原則的には昇格して利用するものであるという印象を受けます。いただけない点があります。提供されているインストーラーからも、それを実行せずに、なんとかして中身のファイルを取り出して配置しようとする点です。ポイントを作成するための機能です。平たく言えば、展開したファイル群の中に含まれるインストーラーをさらに実行してインストールするためのものであって、中身をそのまま実行するためのものではないのです。それでうまく実行できるアプリケーションも少なからずあるとは思いますが、個人的にこれは、アプリケーション作者がサポートしていない利用法であると思います。パッケージは信頼しません。機能の目的外利用を支持しないことを望みます。は煩わしいものですが、もちろんメリットもあります。配置されると読み込んでしまうリスクがあります。ディレクトリ下に配置されていれば、この危険性は、若干ながら軽減されます。検索方法が異なることが書かれています。アプリケーションとは、ただ見た目やインストール方法が異なるのみならず、このようにセキュリティ上のメリットもあるものなのです。アプリケーションはコンテナ環境で隔離されて実行されると言われています。マネージャー、ムツカシイネ。拙速に事を運んで、全部がダメになるようなことがないことを祈ります。行く末を見守りたいと思います。現時点では不安でいっぱいですが。単一ファイルにパッケージングすることを標準でサポートし、さらに利便性が向上しました。コマンドを分けるべきなのかどうか紛糾しているようですが。*3:マルウェアの主流が、システムの中核を破損するような性質のものから、ひっそりと個人情報を抜き取るようなものに変わったことで、メリットは薄れているようにも思います。昇格しなくても抜ける情報を抜かれることに関しては全く無力です。オプション機能を完全に理解した。Testing転職しました。12おことわり当ブログの内容は筆者個人の見解です。筆者が所属するいかなる組織や団体を代表するものでもありません。はてなブログをはじめよう!aetos382さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。