SPDX relationships like DEPENDENCY_OF and TEST_DEPENDENCY_OF seem to be not supported

[maxhbr]

There are some Relationships like TEST_DEPENDENCY_OF are pointing from the test dependency. These relationships are not represented and visualized correctly. Especially, if some SPDX document prefers DEPENDENCY_OF over DEPENDS_ON, it might be listed as having no relationships.

What happened:

As discussed in npm/cli#6867 (comment) the following two sections from SPDX documents are equivalent but yield different representations in this tool.

Variant 1

"relationships": [
  {
    "spdxElementId": "SPDXRef-DOCUMENT",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "DESCRIBES"
  },
  {
    "spdxElementId": "SPDXRef-Package-hello-world-1.0.0",
    "relatedSpdxElement": "SPDXRef-Package-ms-2.1.3",
    "relationshipType": "HAS_PREREQUISITE"
  },
  {
    "spdxElementId": "SPDXRef-Package-hello-world-1.0.0",
    "relatedSpdxElement": "SPDXRef-Package-ci-info-3.9.0",
    "relationshipType": "DEPENDS_ON"
  }
]

visualized as

$ bom document outline ./spdx.json       
               _      
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  < 
|___/ .__/ \__,_/_/\_\
    |_|               

 📂 SPDX Document hello-world@1.0.0
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ hello-world@1.0.0
  │  │ 🔗 2 Relationships
  │  ├ HAS_PREREQUISITE PACKAGE ms@2.1.3
  │  └ DEPENDS_ON PACKAGE ci-info@3.9.0
  │ 
  └ 📄 DESCRIBES 0 Files

Variant 2

"relationships": [
  {
    "spdxElementId": "SPDXRef-DOCUMENT",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "DESCRIBES"
  },
  {
    "spdxElementId": "SPDXRef-Package-ms-2.1.3",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "PREQUISITE_FOR"
  },
  {
    "spdxElementId": "SPDXRef-Package-ci-info-3.9.0",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "DEPENDENCY_OF"
  }
]

visualized as

$ bom document outline ./spdx.json
WARN 2 packages could not be assigned to the SBOM 
               _      
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  < 
|___/ .__/ \__,_/_/\_\
    |_|               

 📂 SPDX Document hello-world@1.0.0
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ hello-world@1.0.0
  │  └ 🔗 0 Relationships
  └ 📄 DESCRIBES 0 Files

What you expected to happen:

As they are describing the equivalent graph I would expect both to have similar representations in the tool. But the tool fails to identify that the second one has relationships at all.

There are some which could just be "normalized" on parsing, e.g. a DEPENDENCY_OF relationship could be converted to its DEPENDS_ON representation.

Some other types have no inverse, like BUILD_DEPENDENCY_OF, DEV_DEPENDENCY_OF, OPTIONAL_DEPENDENCY_OF, PROVIDED_DEPENDENCY_OF and TEST_DEPENDENCY_OF. For those there should be a way to show arrows which are pointing from the "smaller" to the "bigger". Maybe by introducing names for the inverse or with some ASCII art.

[goneall]

I agree tools should support the inverse direction for relationships in the parsing tools.

There are scenarios where the inverse relationship is created since the relationship is not known when the first component is created making it more convenient to add the reverse relationship to the second component rather than amending the first.

In the case of no inverse relationships - I personally think it would be OK if the tool just output a relationship type that isn't in the spec, but makes sense - e.g. BUILD_DEPENDS_ON for BUILD_DEPENDENCY_OF.

[zvr]

Another reason to support reverse relationships is preparing for the future: SPDXv3 removes the "dual" relationships.
There is still a DEPENDS_ON but no more DEPENDENCY_OF, for example.
Having both would unnecessarily complicate things, as there are (till now) 64 relationship types and we don't want to have 64 reverse ones.

[maxhbr]

ping @puerco , can you please chime in here and clarify your opinion on the ticket?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[maxhbr]

Hey, I think this is still valid. Can someone please have a look?

[cpanato]

@maxhbr yep seems valid, are you willing to open a pr to get this fixed?

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.