Add new relationship DEPENDENCY_MANIFEST_OF

[tsteenbe]

DEPENDENCY_ROOT_OF to describe the relationship from package to package to describe the root of the dependency tree. Motivation: This relationship allows SPDX creator to tell which package is the root of a dependency tree for a specific package without any SPDX render will not now how to render a SPDX as a tree.

This issue is continuation of #168

[swinslow]

I'm trying to make sure I understand this, so here's a concrete example and some questions :)

Let's say I'm preparing an SPDX file for https://github.com/swinslow/containerapp. That repo has two main directories:

• api/ which has a Dockerfile and some Golang files
• webapp/ which has a Dockerfile, a package.json manifest and some JavaScript files for use with React

So we're talking a mix of Golang, NPM/JavaScript and Docker containers (as well as a smattering of other things, but ignore those)

I think the idea you're proposing is that there would be one "top-level" package, say SPDXRef-containerapp; and that each of its direct dependencies would use DEPENDENCY_ROOT_OF to that package? e.g.:

SPDXRef-containerapp DEPENDENCY_ROOT_OF SPDXRef-golang-library-whatever
SPDXRef-containerapp DEPENDENCY_ROOT_OF SPDXRef-react
SPDXRef-containerapp DEPENDENCY_ROOT_OF SPDXRef-random-container

and then subdependencies would also use DEPENDENCY_ROOT_OF to point up to their parent:

SPDXRef-react DEPENDENCY_ROOT_OF SPDXRef-some-react-subdep

and (this is the part I'm particularly unclear on) that it would be semantically invalid for any dependency to be in the tree for more than one component, because that would create a cycle and/or a node with multiple parents:

SPDXRef-react DEPENDENCY_ROOT_OF SPDXRef-another-react-subdep
# INVALID
SPDXRef-random-container DEPENDENCY_ROOT_OF SPDXRef-another-react-subdep

Is that the idea?

I might be way off-base here from what you're picturing... just trying to put some concrete terms around what the proposal is, because I'm having trouble articulating the intended difference between it and existing Relationships for dependencies.

[kestewart]

Discussion on call, name may need to be revisited. This is the file that defines all the dependencies is useful. Metadata file was sort of intended for this, but Gary sees the value.
Dependency metadata file, dependency manifest of, ??? Seems to be agreement on "dependency manifest of" to describe this specific type of metadata. One side is pkg.json, and other side is entire github repository. From manifest identifier, could use other dependencies, like "build dependency", between manifest and package being analyzed? AI: Thomas to create an example.

[tsteenbe]

Example as requested based on https://github.com/heremaps/oss-review-toolkit/blob/master/reporter-web-app/package.json

SPDXRef-doc-ort
SPDXRef-ort-web-app DEPENDENCY_ROOT_OF SPDXRef-doc-ort
SPDXRef-react DEPENDENCY_OF SPDXRef-ort-web-app
SPDXRef-eslint DEV_DEPENDENCY_OF SPDXRef-ort-web-app
SPDXRef-jest TEST_DEPENDENCY_OF SPDXRef-ort-web-app

[kestewart]

From call preference instead of DEPENDENCY_ROOT_OF, use DEPENDENCY_MANIFEST_OF.

[swinslow]

Example wording: "Is to be used when SPDXRef-A is a manifest file that lists a set of dependencies for SPDXRef-B"

[swinslow]

For the example: "A file package.json is the dependency manifest of a package NPMApp"

[kestewart]

In the case of the NPM example, we expect that the package.json file will be the dependency manifest of, and the package-lock.json will be generated from. Lock files should not be considered as dependency-manifests. Key here is we need a root for dependency tree, and if we're using dependency_manifest, we want to make sure its considered root implicitly.

From call, we'll go with a PR for dependency_manifest, and document that there is only one so it can be considered as root.

[kestewart]

@tsteenbe - an estimate on PR?