「パッケージ管理システムを複数導入する」ことは一般的に好ましくないのか

新米
1

概要

「パッケージ管理システムを複数導入することは、一般的に好ましくないものである」
という認識は、果たして合っているのでしょうか。

なぜそう思うのか

一元管理できなくなる懸念

例えば、Aというパッケージ管理システムでRubyをインストールしたとします。
次に、Bというパッケージ管理システムでPythonをインストールしたとします。

ここで、RubyとPythonをアンインストールする場合、

  • Aというパッケージ管理システムではPythonをインストールしていないため、アンインストールできない
  • Bというパッケージ管理システムではRubyをインストールしていないため、アンインストールできない

ような事象が、感覚的には発生するのではないかと思ってしまいます
（詳しく検証したわけではないため、分かりません）。

もしこのような事象が発生するのであれば、
「一元管理できたほうがいいよね」ということで、どちらかに統一するべきなのかと思ってしまいます。

npmとyarnの論争

Linuxではありませんが、Node.jsのパッケージ管理システムでは、
「npmとyarnではどちらが優れているか」という記事をよくお見かけします。

ここで結論を見ると、
「両方導入する」という選択肢はそもそも用意されていないように見えます。

つまり、どちらか一方に統一するべきなのかと思ってしまいます。

__
そもそも私が、パッケージ管理システムというものに感覚的に慣れていないことも大きい気がします。
どなたか見識のある方いらしたら、ぜひご回答をよろしくお願いします。

2

異なる複数のものが混在しているため、前提が間違っています。

まず、システムのパッケージ管理と、npmのようなライブラリ管理は全く別の話です。

システムのパッケージ管理の場合、高度になるほど同一のデータベースを共有しないパッケージ管理は重大な問題を引き起こします。
例えば、AパッケージがRequires B, C, Conflict Dだとして、別のパッケージ管理システム上でC, Dがインストールされているとします。
すると、Aパッケージをインストールしようとするとき、Cパッケージはすでに存在しているにも関わらず、「ない」と認識されて導入されるため、システムが破壊されます。
また、Dパッケージがインストールされていることを認識されないため、不整合を生じます。
通常のデスクトップシステムは人間がとても認識できないほど複雑な依存関係を持っているため、複数のパッケージングシステムを導入すれば間違いなく問題を生じます。
これが、同じデータベースを使うものなら基本的に問題ありません。例えばdpkgとaptとか。

さて、npmとyarnの場合、システムパッケージと同列で考えることはできませんが、データベースはpackage.jsonであり、導入先兼データベースはnode_modulesなので、別にどっちでも構いません。
特に、単にライブラリをインストールする目的であればどっちでも良いです。
ただし、設定やスクリプトの書き方はそれぞれ違いがあったりしますかから、併用すると同じ内容をnpm向けとyarn向けで書かなければならないことがあります。個人的にやる分には構いませんが、プロジェクトマネジメントとしてはとても悪いので、公開する場合は「お下品」です。

「いいね！」 1
3

@harukamy さん

ご回答ありがとうございます！

こちら回答を全文読んだ上で、理解が正しいか確認したいです：

  • ライブラリ管理では、データベース共有されない事象は通常発生しない？
  • システムのパッケージ管理とライブラリ管理では、依存関係の管理が異なる？

別の話、であることは何となく分かりましたが、
「なぜ同列で考えることができないのか」がよく分かりませんでした。

「同じデータベースを使っているか否か」という説明は、なるほどという感想です。
pacmanとtrizenを併用しても問題ないのは、これが理由になるのかな、と思いました。

4
  • ライブラリ管理では、データベース共有されない事象は通常発生しない？

いいえ

  • システムのパッケージ管理とライブラリ管理では、依存関係の管理が異なる？

半分はい
内部に完結しているかどうかと、競合がいかにして発生するかが違います。

別の話、であることは何となく分かりましたが、
「なぜ同列で考えることができないのか」がよく分かりませんでした。

システムの場合は起動できなくなったり動作しなくなったりするからです。
ライブラリの場合は単にパージすればいいだけなので、そんな深刻な自体を想定した構造になっていませんし、パッケージマネージャの挙動が大きく異なります。
もちろん、そんな複雑なことは考えず、ファイルがあれば上書きするだけのシステムパッケージマネージャも存在しますが。

例えばシステムでは、「同じ機能を果たそうとするために同時に存在するとシステムが動かなくなる機能」というのもあります。
しかし、ライブラリの場合はロードしなければ良いだけなので、そういうことは基本的にはありません。競合は同じファイルを上書きすることによって発生する程度ですが、一般的にライブラリはファイル自体がパッケージの名前空間の下にいるため、それも発生しません。
システムのパッケージはインストールする内容は「システムのファイルとして」存在しなければならないのが普通なので、簡単に競合します。

pacman とtrizen を併用しても問題ないのは、これが理由になるのかな、と思いました。

trizen はパッケージ操作に pacman を使っているので、これはまた別の話です