答案1
是否可以?是的。這兩個程式都是開源的。方便嗎?並不真地。
為什麼?
套件管理器的工作方式或多或少是這樣的:
- 他們追蹤您系統上安裝的軟體包(及其版本)
- 為此,他們指定自己的套件格式(例如 .deb),並使用這些套件作為如何安裝程式以及如何追蹤程式的說明
- 他們還追蹤依賴性(例如「這個程式需要 openssl 才能工作!」)
這就是為什麼擁有一個使用很少套件管理器的系統並不是最好的主意:
- 每個套件管理器都必須了解正在安裝的套件(例如,
brew
必須知道您安裝了firefox
,並且apt
必須知道您安裝了tldr
) - 每個套件管理器都必須解決其他套件管理器的依賴關係(例如“Brew:這個程式需要
ncurses
,但apt
已經安裝了ncurses
,所以我不需要拉它們!”)。
您會看到,問題在於2
套件管理器是底層儲存庫的抽象。像 Debian 人員這樣的人選擇他們希望用戶使用的軟體包,並將它們提供給其他人。然而,他們也選擇這些軟體包,以便系統保持一致;他們希望用最少的包來提供最多的功能。當 ncurses 版本 2 可以正常運作時,為什麼還要安裝 ncurses 版本 1,2 和 3?
第一個問題也是個壞消息。套件管理器必須互相告知他們所做的事情,否則他們可能會發生衝突(brew
不知道ncurses
已經安裝了)。
那為什麼很難呢?
- 套件管理器需要緊密合作
- 包管理者必須制定嚴格的政策,規定當他們無法就包達成一致時該怎麼做
- 套件管理器必須能夠幾乎互換地工作,唯一可見的區別是可用的程序
- 套件管理器必須能夠在更新時追蹤彼此的儲存庫。
這實際上意味著您需要一個由兩個套件管理器組成的套件管理器。您需要一個新程式。
那我能做什麼呢?
首先,我會問自己「我為什麼要這樣做?」。老實說,您的發行版應該為您提供大量的軟體包。如果您對擁有的軟體包數量不滿意,您可以考慮切換到擁有更多所需軟體包的其他發行版。
如果你是真的迫切希望讓它brew
發揮作用,我會提出以下解決方案,儘管我不確定這是否完全可能:
- 抓住 的來源
brew
。 - 了解釀造配方格式。
- 編寫一個程序,自動將食譜轉換為 Debian 軟體包。
- 進行修改
brew
,以便每當您運行它時,它都會調用該程序將配方轉換為.deb
包/搜尋發行版存儲庫中的程序,然後調用apt
以安裝此包。
進行這樣的修改可能會花費很多時間,而且並不是一件容易的事。我建議更改發行版或堅持使用套件管理器。
答案2
是的,但這將是一種不小的浪費。製作一個更有意義聚苯胺對於 tldr 或讓它被主要 Debian 存儲庫接受,或者只是使用https://tldr.ostera.io。