答え1
それは可能ですか? はい。両方のプログラムはオープンソースです。便利ですか? そうではありません。
なぜ？
パッケージ マネージャーは、おおよそ次のように動作します。
- システムにインストールされているパッケージ（およびそのバージョン）を追跡します
- これを行うには、独自のパッケージ形式（例：.deb）を指定し、これらのパッケージをプログラムのインストール方法と追跡方法の指示として使用します。
- また、依存関係も追跡します (例: 「このプログラムが動作するには openssl が必要です!」)
このため、パッケージ マネージャーをほとんど使用しないシステムを持つことは最善のアイデアではありません。
- 各パッケージ マネージャーは、インストールされるパッケージについて通知を受ける必要があります (たとえば、
brewがインストールされたことを知る必要がありfirefox、aptがインストールされたことを知る必要がありますtldr)。 - 各パッケージ マネージャーは、他のパッケージ マネージャーからの依存関係を解決する必要があります (例: 「Brew: このプログラムには が必要です
ncursesが、aptすでにインストールされているncursesため、それらをプルする必要はありません!」)。
問題は、2パッケージ マネージャーが基礎となるリポジトリの抽象化であることです。Debian の開発者のような人々は、ユーザーに使用してもらいたいパッケージを選択し、他のユーザーが使用できるようにします。ただし、システムの一貫性を保つためにもこれらのパッケージを選択します。つまり、最小限のパッケージで最大限の機能を提供したいのです。バージョン 2 ですべてが機能するのに、なぜ ncurses バージョン 1、2、3 をインストールするのでしょうか。
最初の問題も悪いニュースです。パッケージ マネージャーは、お互いに何をするかを知らせ合う必要があります。そうしないと、衝突する可能性があります (すでにインストールされているかどうbrewかがわかりませんncurses)。
では、なぜ難しいのでしょうか?
- パッケージマネージャは緊密に協力する必要がある
- パッケージ管理者は、パッケージについて合意できない場合にどうするかについて厳格なポリシーを持たなければならない。
- パッケージマネージャは、利用可能なプログラムの違いのみを目に見える形で区別し、ほぼ互換性を持って動作する必要がある。
- パッケージ マネージャーは、更新があった場合に互いのリポジトリを追跡できる必要があります。
これは実質的に、2 つのパッケージ マネージャーで構成されるパッケージ マネージャーが必要になることを意味します。新しいプログラムが必要になります。
じゃあどうすればいい？
まず最初に、自分自身に「なぜこれをやりたいのか」と問いかけます。正直なところ、ディストリビューションは十分なパッケージを提供する必要があります。パッケージの数に満足できない場合は、必要なパッケージがさらに多い他のディストリビューションに切り替えることを検討してください。
あなたがいる場合本当にこれを機能させたいのでbrew、次の解決策を提案しますが、これが完全に可能かどうかはわかりません。
- のソースを取得します
brew。 - 醸造レシピの形式を学びます。
- レシピを Debian パッケージに自動的に変換するプログラムを作成します。
brew実行するたびに、レシピを.debパッケージに変換するプログラムを呼び出し、ディストリビューションのリポジトリ内のプログラムを検索し、aptこのパッケージをインストールするように変更します。
このような変更を行うには、おそらく多くの時間がかかり、簡単なことではありません。代わりに、ディストリビューションを変更するか、パッケージ マネージャーを使用することをお勧めします。
答え2
はい、でもそれは無駄な労力です。ppatldrやメインのDebianリポジトリに受け入れられるようにするには、または単にhttps://tldr.ostera.io。