Linux向けソフトウェアのパッケージングが嫌いだ

Linux向けソフトウェアのパッケージングが嫌いだ Freshを誰にでも、どこでも簡単にインストールできるようにしたかっただけなのに、それがどれほど難しいことか！ WindowsとmacOSは比較的均一なので、それほど悪くはありません。Windowsでは、wingetを使用しています。見た目は悪いですが、機能します（最初の苦労を乗り越えれば）。macOSでは、今はhomebrewを使用していますが、理想的ではありませんが、セットアップは難しくありませんでした。正しくパッケージ化する時間を取れれば、よりネイティブな署名付きMacアプリに移行するでしょう。どちらのソリューションも、現代のWindowsおよびmacOSユーザーにはまあまあ機能します。 Linuxは話が異なります。Freshをnpmパッケージとしてリリースすることから始めました。これは見た目が悪く、HNで一部の人を怒らせましたが、実際の問題もありました。 セキュリティ - npmjsはすでに複数の侵害を受けており、私はもっと安心して眠りたいです。 普遍的ではない - 多くのユーザーはnpmをインストールしていません。Freshをインストールするためだけにnpmをインストールする理由は何でしょうか？ 奇妙なインストーラー - npm installフローは、実際にはnpmjsから取得したスクリプトであり、githubにアクセスしてマシンに合った正しいバイナリ成果物をダウンロードします。更新するたびにこれを行う必要があります。 そこで、怒っている人々のフィードバックに耳を傾け、（いくつかの親切な貢献者の助けを借りて）「すべて」のパッケージを作成しました。 crates.ioのrustのcargo（およびcargo-binstall） AppImageやFlatpakのようなディストロに依存しないもの deb rpm AUR（Arch Linux）、2つのバリアント - ソースビルドとプリビルドバイナリ - binパッケージ nix homebrew for linux（いったい何？） npm / npx Terra Gentoo GURU さらに、プリビルドバイナリをtarballとしてリリースしています。これらすべてがいかに壊れやすいか想像できるでしょう。リリースごとに、多くのチャネルのいずれかで問題に遭遇するのではないかと心配になります。 これらのソリューションのどれも、一部のユーザーには機能しますが、すべての人に機能するものはありません。そして、それらすべてに欠点があります。 「なぜnixを使わないんだ？！」 多くの人がNIXをインストールしておらず、私のアプリを使うためだけにインストールしたくないからです。私はnixを方法としてサポートしていますが、それはすべての人に機能するわけではありません。 「Flatpakを使えばいい！」 Flatpakもリリースしていますが、実際にはそれに反対して作業しています。それは自己完結型のサンドボックス化されたデスクトップGUIアプリケーション用に設計されており、私はマシンやネットワークを自由に操作できるターミナルベースのTUIをリリースしています。動作させるために、いくつかのひどい「悪いプラクティス」フラグを渡しています。Flatpakのサンドボックス化は適切ではありません。 「AppImageを使えばいい！」 AppImageもリリースしていますが、squashfsのFUSEマウントオンデマンドのために実行が非常に遅く、起動時間が許容できないほど遅くなります。プログラムは技術的に可能な限り速く、瞬時に起動してほしいです。起動時間を現実的なものにするために、私のインストーラースクリプトは、squashfsの内容をどこかに抽出し、AppImageをドロップするひどいハックを組み込んでいます。必要であれば、AppImageを直接実行することもできますが、起動が非常に遅くなります。そして、どちらの場合もFUSEのインストールが必要です。なぜ私のアプリにFUSEが必要なのですか？！ また、私のバイナリは最小限のlibcバージョンを必要とするため、実際には普遍的にポータブルではありません（そのため、2〜3年前のディストロでは機能しない可能性があります）。したがって、静的リンクを使用し、AppImageをドロップしても構いません。何らかの理由で、AppImageだけがこのポータビリティの問題を解決すると想像していました。 最後に、さまざまな理由で、多くの人がAppImageやFlatpak（およびSnap）に対して悪い見方をしており、それらを使用することを拒否するでしょう。私は負けました。 Debianファミリーの苦痛 この他のHNの議論で説明したように、私の.debをDebian（およびUbuntu）の公式パッケージとしてプッシュする作業ができていません。なぜなら、それには（多くの）Rust依存関係もDebianパッケージである必要があるからです。このポリシーには多くの良い理由があります - 任意のパッケージの完全に再現可能で自己完結型のビルド、サプライチェーンの地獄を減らすなど - しかし、それは多くの作業です。そして、どうやって追いつくことができるでしょうか？私の直接の依存関係のすべてが、セキュリティ問題などが発生するたびにDebianで再更新される必要があります。私にはその時間はありません。ソースとして依存関係をすべてdebソースパッケージにベンダーすることはできません。それはポリシーに反します。 もう一つの楽しい逸話は、古いUbuntu（そしておそらく古いディストロ）を実行している古いマシンをサポートしたいということです。しかし、これらのマシンは古いlibcを持っているため、新しいUbuntu用にビルドしたものが古いマシンにインストールできない可能性があります。なぜなら、バイナリロード時にリンクエラーが発生するからです。そのため、古いUbuntuコンテナイメージでビルドし、そのパッチが当たっていないパッケージをビルドに引き継ぐ必要があります。または、それらのユーザーを完全にドロップする必要があります。どちらの選択肢も成り立ちません。 .deb / .rpmの自動更新なし それが非常に面倒なため、私のパッケージ.deb（または.rpm）は公式ソースに受け入れられていません。したがって、これらのパッケージをインストールしたユーザーは、システムのネイティブパッケージ更新メカニズム（apt-get upgradeなど）を実行しても自動更新を受け取れません。単一パッケージの新しいバージョンを探すURLを指定するだけで、aptとdnfの両方がそれを覚えてパッケージを更新するような、迅速なサーバーレスソリューションがあればよかったのにと思います。 ここで「正しい」こと、つまりパッケージを公式チャネルに入れることはよく理解しています。Fedoraのためにbugzillaを作成し、Ubuntuのために何らかのものを開始し、投票などがありますが、これらのリクエストを推進する時間とエネルギーがありません。私はただ私のソフトウェアを配布したいのです。私の言いたいことは、人々はさまざまなディストリビューションを使用しているため、これを行うための複合的な労力は非常に高いということです。 Miseは機能したが、その後機能しなくなった 一部のユーザーがMiseをローカル（ユーザーレベル）パッケージマネージャーとして使用していることが判明しました。誰かがFreshで動作するようにしました。素晴らしいことです！しかし、ある日、私の側で何も変更がないのに動作しなくなりました。GitHubがビルドアテステーションシステムの証明書をローテーションし、Miseが現在の信頼ルートを取得する代わりに古い信頼ルートをピン留めしていたことが判明しました。誰かが文句を言うまで、何も壊れているとは知りませんでした。結局自分で修正しましたが、なぜそのような問題に時間を費やす必要があるのでしょうか？私は自分が何をしているかさえわかっているのでしょうか？Miseはクールで、私もいくつかのプロジェクトでそれを使用していますが、ソフトウェアツールの作成者としては、考えるべきことがあまりにも多すぎます。 Arch Linux AUR 私は個人的にArch AURを使用しており、このチャネル（ソースとプリビルドの-binパッケージの両方）を通じてFreshを提供していますが、最近新しいパッケージリリースがブロックされています。AURはセキュリティ侵害のため読み取り専用モードになっているため、すでに数回のバージョンリリースを逃しています。今のところ、AURがいつ再開されるかは全くわかりません。緩和策として、FreshをAURではなくArchのextraリポジトリに入れるようにメンテナーに連絡しました。それが解決策になるかもしれません。 これらの不満のすべてから得られる結論は、ディストリビューション固有のチャネルは良い解決策ではないということです。ディストリビューションとバリアントの数が増えるにつれて、マイナーなパッケージでさえリリースすることがほぼ不可能になっています。 次のステップ：静的リンクされたmusl、自己更新バイナリに焦点を当てる パッケージマネージャーは本当に必要でしょうか？ すでにリリースの一部としてmuslバイナリをビルドしています。次のバージョンには、ユーザーがオンデマンドでトリガーできる新しい組み込みの自己更新メカニズムが含まれます。これがLinuxの主要なリリースチャネルとなり、おそらく今後サポートする必要がある唯一のチャネルになるでしょう。既存のすべてのパッケージは、少なくとも今のところサポートされ続けます。目標は、静的バイナリを推奨されるデフォルトにすることです。デフォルトにすることで、リスクを冒しています。なぜなら、それがもたらす他の驚きが何であるか誰が知っているでしょうか？一部の人々にとって私の静的リンクバイナリを壊すLinuxのポータビリティの問題です。今のところ、ソースからビルドしたり、まだリリースしているパッケージファイルを使用したりすることもできます。 基本的に、私は独自の小さなパッケージマネージャーを実装しています。それはすべての人に機能するでしょうか？うまくいけば！Freshは約12MBのダウンロードで、展開すると約35MBになるため、全体として合理的なエクスペリエンスになるはずです。最終的なバイナリサイズの削減にも常に取り組んでいます。 他に何かできることはありますか？