ベストアンサー1
可能ですか？はい。どちらのプログラムもオープンソースです。便利？まさか。
なぜ？
パッケージマネージャの仕組みはおおよそ次のとおりです。
- システムにインストールされているパッケージ（およびそのバージョン）を追跡します。
- これを行うには、独自のパッケージ形式（.debなど）を指定し、これらのパッケージをプログラムのインストール方法と追跡方法のガイドラインとして使用します。
- また、依存関係を追跡します（例：「このプログラムが機能するにはopensslが必要です！」）
これが少数のパッケージマネージャを使用するシステムを持つことが最善のアイデアではない理由です。
- すべてのパッケージマネージャは、どのパッケージがインストールされているかを知る必要があります（たとえば、
brewそのパッケージをインストールしたこととインストールしたことをfirefox知るapt必要がありますtldr）。 - 各パッケージマネージャは、他のパッケージマネージャの依存関係を解決する必要があります（例：「Brew：このプログラムには必要です
ncursesが、aptすでにインストールされているのでncursesインポートする必要はありません！」）。
ご覧のとおり、問題は2パッケージマネージャが基本リポジトリの抽象化であることです。 Debian の人のような人は、ユーザーが使用したいパッケージを選択し、他の人が使用できるようにします。ただし、システムが一貫性を保つようにこれらのパッケージを選択したり、最小限のパッケージで最大の機能を提供したいと思います。 ncursesバージョン2が正常に動作するのに、なぜncursesバージョン1、2、3をインストールするのですか？
最初の問題も悪いニュースだ。パッケージマネージャは、自分が行っていることを互いに知らせる必要があります。そうしないと、競合が発生する可能性があります（何がインストールされているかbrewわからない）。ncurses
それではなぜそんなに難しいのですか？
- パッケージマネージャは緊密に協力する必要があります。
- パッケージ管理者は、パッケージに同意できない場合に実行するアクションに関する厳格なポリシーを持っている必要があります。
- パッケージマネージャはほとんど交換可能でなければならず、唯一の顕著な違いは利用可能なプログラムです。
- パッケージマネージャは、更新時に互いのリポジトリを追跡できる必要があります。
これが実際に意味するのは、2つのパッケージマネージャで構成されるパッケージマネージャが必要であるということです。新しいプログラムが必要です。
だから私は何ができますか？
まず、「私はなぜこの仕事をしているのか」と自分に尋ねます。正直なところ、ディストリビューションは多数のパッケージを提供する必要があります。保持しているパッケージの数が満足できない場合は、必要なパッケージを他の多くのディストリビューションに切り替えることを検討できます。
あなたならどうでしょうか？本物これを正しくbrew機能させるために、次の解決策を提案します。しかし、これが完全に可能かどうかはわかりません。
- ソースをつかむ
brew。 - 醸造レシピの種類について学びます。
- レシピをDebianパッケージに自動的に変換するプログラムを書いてください。
brew実行するたびに、.debレシピをパッケージに変換するプログラムを呼び出し、配布リポジトリからプログラムを検索し、このパッケージをインストールするように呼び出すように変更しますapt。
これらの修正作業には時間がかかり、簡単な作業ではありません。ディストリビューションを変更するか、パッケージマネージャを使用することをお勧めします。