11
私は依存アルゴリズムに問題があります。依存関係は厳密なバージョンスコープに基づいていることを除いて、依存関係はmaven依存関係と似ています。例えばバージョンスコープベースの依存関係を解決するアルゴリズム
：
component A, version 1 depends on: component B, version 1~3; and component C, version 2~3
component D, version 1 depends on: component B, version 2~4; and component C, version 1~2
は今、私は、成分A、バージョン1および成分D、バージョン1をインストールしたい場合、彼らはすべてのコンポーネントBに依存しているため、依存関係を取得したい、Cので、私また、より多くのBとC
の正しいバージョンを取得するには、正しいアルゴリズムを必要とする、私は例えば、成分AとDをアップグレードする必要があり、今私は、新しいバージョンの下にあります
component A, version 2 depends on: component B, version 3~5; and component C, version 4~5
component A, version 3 depends on: component B, version 6~7; and component C, version 4~5
component D, version 2 depends on: component B, version 3~4; and component C, version 3~4
これで、AとDの正しいバージョンを取得するためのアルゴリズムと、そのすべての依存関係をアップグレードする必要があります。 1つの問題はコンポーネントAのバージョン3とコンポーネントDです。バージョン2はコンポーネントBの依存関係の競合があります
この問題を解決する既存のアルゴリズムはありますか？または同様の（簡単な）問題。提案はありますか？
データがたくさんあるべきではないので、パフォーマンスを考慮しないでください。
ありがとうございます！
簡単な解決策として、トポロジカルソートを使用できますか？まず、すべてのノードが{ノードID、バージョン番号}であるグラフを作成します。その後、トポロジカルな並べ替えを行って依存関係の順序を取得します。 – trequartista
私のケースでは、依存関係は1つのコンポーネントバージョンを解決するだけで済みます。したがって、同じノードIDを持つノードのグラフを作成する場合、出力リストは1つのノードのみを出力する必要があります。いくつかのノードでは、それらのバージョンが競合する可能性があるため、そのようなノードは決して出力リストに存在しない可能性があります。この問題を解決するには？ – Xilang
いいえ、私はどういう意味ですか、各ノードにはノードIDとバージョンIDの両方があります。すなわち、 {Component A、version 1}と{Component A、version 2}は異なるノードです。したがって、例えば： – trequartista