依存関係の伝播をどのように理解する必要がありますか？ [閉鎖]

「ダウンストリーム」と「アップストリーム」の依存関係はどういう意味ですか？

のようにMC68020の回答、パッケージA、B、Cを使用します。ここで、AはBに依存し、Bは再びCに依存します。

A→B→C(依存関係の観点から).

「上流」および「下流」という用語は、変化する流れを指す。

• 通常、デプロイメント環境では、「アップストリーム」とは、通常、パッケージに提供されるプロジェクトのソースソースを指します。そこで変更が適用され、パッケージが更新され、更新されたプロジェクトが提供されます。

• 特に依存関係の文脈でCが変更された場合は、Bも変更する必要があり、Aも変更する必要があります。したがって、CはBの上流の依存関係、BはAの上流の依存関係、AはBの下流の依存関係、BはCの下流の依存関係です。

「間接」依存関係と「直接」依存関係は何ですか？

直接依存関係は直接依存関係を意味します。 BはAの直接依存性、CはBの直接依存性です。間接依存関係は転移的依存関係です。 A は B のため C にのみ依存するため、C は A の間接依存関係です。 A が B に依存しないように変更されると、C に依存しなくなります。

依存関係の概念はパッケージの依存関係間で依存関係を伝播しますか？

依存性の反映の伝播多様性依存関係ツリーから。から始まる

A→B→C

上記で、AがCの一部の機能を使用するように変更された場合、Cに直接依存します。

A→B→C
A→C

C の観点からは、以前の間接依存関係 A は直接依存関係として必要であるため、依存関係は「伝播」されています。伝播は C または依存ツリーに依存せず、A の変更の結果です。

これらの変更は目立たない可能性があるため、記録しておくことが重要です。 BはCに依存するため、AはCの機能に「無料」でアクセスできます。したがって、AがCを直接使用し始めると、パッケージングの変更は必要なく、Aは通常どおり構築し続けます。しかし、Aの直接依存関係リストは現在不完全であり、Bが後でCの依存関係を削除すると、Aから何も変更されていない場合でも、Aはビルドを停止します。

簡単に言えば、Ａ、Ｂ、ＣはそれぞれパッケージＡ、パッケージＢ、パッケージＣを表す。

AがBに依存する場合、Aの一部のコードがBで定義されている外部参照を取得することを意味します。

AがBに依存し、A自体がCに依存すると仮定します。

Bの場合、Aは次のように言うことができます。上流（ある人はAと呼ぶことがあります。リバース依存性B）と下流。

B だと言える。即時Aの依存性。
しかし、BはCに依存するので、Cは次のように言うことができます。間接的な 依存関係。これが正しい場合、CはAへの外部参照を定義しないためです。 AはCのすべての美徳に依存します。転移性（数学的意味では、A - >（とにかくB - > C = > A - > Cに関連する）

さて、AもCに依存すると仮定しましょう。 glibcを最も一般的な例として考えることができます。 （Aが依存する他のライブラリもglibcに依存しているため、Aの一部のコードはいくつかのglibc関数を呼び出す可能性があります。

これにより、CはAとBの直接的な依存関係になります。この場合、Cの依存関係を呼び出します。広げる。

困難な状況が発生する可能性があり、これによって一部の結果が生じる可能性があります。

あいまいな/混乱

計算計算：A - > B - > C - > D - > Bの場合

Aの直接依存性であるBはDの直接依存性でもあり、DはBの間接依存性でもあります。その結果（OPにリンクされているページ参照のように）

依存関係の転移的閉鎖