Thanks Jack. This is certainly helpful and makes good sense. My first thought is about parallel language in the relationships. The two terms originate from different spots in the spec. I think we can accomplish the dependency relationships with what you suggest but what about something that is focused on dependencies? Depends_On?
matt On Thu, Jan 14, 2016 at 2:58 PM, Manbeck, Jack <[email protected]> wrote: > To be more specific on this: > > > > “I would envision Contains used to describe what is being delivered as a > use case of what you describe in your email. If the HTTPserver also was > distributed with openssl then it could also use contains. If openssl wasn’t > being delivered, then generated from makes more sense. In the case of where > it is, you could use both contains and generated from.” > > > > I would use contains if the delivery had both the httpserver and say an > openssl library or source. If was just one executable only (everything > statically linked), then I would definitely only use generated from. > > > > Jack > > > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Manbeck, Jack > *Sent:* Thursday, January 14, 2016 3:53 PM > *To:* Matt Germonprez; [email protected] > *Subject:* RE: Relationships and Dependencies > > > > Matt > > > > I seem to recall we had some discussions around this when working on the > 2.0 relationships. If you had a binary element, you could relate it to > source packages by using GNERATED_FROM. I don’t believe we adopted a source > to source relationship specifically. Therefore you could have an spdx > document for the HTTPServer and then an element within that server for the > binary that then uses generated from for other documents and elements that > were used to build it, like say OpenSSL and even its own code. I doubt this > makes sense, in hindsight, for interpreted languages not because they are > source but because one doesn’t necessarily generate the other. > > > > I would envision Contains used to describe what is being delivered as a > use case of what you describe in your email. If the HTTPserver also was > distributed with openssl then it could also use contains. If openssl wasn’t > being delivered, then generated from makes more sense. In the case of where > it is, you could use both contains and generated from. > > > > There is definitely some pipe cleaning to be done on these. > > > > Jack > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] > *On Behalf Of *Matt Germonprez > *Sent:* Thursday, January 14, 2016 3:11 PM > *To:* [email protected] > *Subject:* Relationships and Dependencies > > > > SPDX Tech, > > > > At UNO, we are currently working on things that have to do with > RELATIONSHIPS. Specifically, we are thinking about how SPDX can be used > against packages with dependencies. I think that RELATIONSHIPS are the way > to go here but this is no easy task. Here are a few of the > questions/comments that have been raised by the team: > > > > 1) What RELATIONSHIP keyword should be used to describe a dependency (For > example, if package *httpserver* depends on package *openssl*) from > one SPDX document (or package) to another SPDX document (or package)? It > seems that the closest keyword I can see would be *PACKAGE_OF*, but that > seems to be the backwards relationship (child to parent) of what we want > (that would only tell us that *openssl* is a package of *httpserver*). I > think we might want more of a *PACKAGE* relationship, but sadly, this > doesn't exist in the current SPDX spec. > > > > 2) Contains and Contained_BY seem to appropriate for showing package and > sub package relationship. Can we create relationships between > dependencies document by creating a list of Contains and Describes > relationships? > > > > Thoughts on this are most welcome. > > > > Regards, > Matt > > > > -- > > Mutual of Omaha Associate Professor > > College of Information Science & Technology > > University of Nebraska Omaha > -- Mutual of Omaha Associate Professor Information Systems College of Information Science & Technology University of Nebraska Omaha http://ocrl.unomaha.edu/
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
