Should a dependency tree be scoped to a single project ?

[Hritik14]

As being discussed in #885, we need to improve the Package and Dependency relationships to support transitive dependencies.

During this, should a dependency tree be specific to a single project being scanned or shared across all the projects.
Say, for example:

purl A
    +------purl B
    +------purl C
                +------purl D

here, whenever and wherever we find purl A, we know - for sure - that the above dependency tree will be present. Same applies for purl C (purl D will always be a dependency) regardless of the project being scanned.

Would it make more sense to have a central dependency relationship mapping as the source of truth for entire SCIO that will be ever-evolving with every scan performed ?

There is one caveat to this approach, let's say purl C changes its dependency from purl D to purl E at some point of time after the scan was run. This breaks the entire hypothesis of having a central dependency mapping source of truth.
Ideally, purls should not change dependencies at points of time but we live in a weird world.

[keshav-space]

Keeping a shared dependency tree across projects will only work when the transitive dependencies at all levels are pinned, and even then there is good reason for developers to tinker with the transitive dependencies inside their own project. IMO, it would be much more practical to keep the dependency tree at project level.