Hi Yev,
I've added it as a topic to be added to the agenda to
the upcoming meetings page.
see: http://wiki.spdx.org/view/Technical_Team/SPDX_Upcoming_Meetings
We can discuss when it should go in agenda for discussion in today's
meeting.
Kate
On Mon, Jul 6, 2015 at 5:22 PM, Yev Bronshteyn <
[email protected]> wrote:
> As I was going through the best practices for indicating external
> dependencies, I realized that there doesn’t seem to be one for dependencies
> that are known at the package level rather than the file level. A component
> developer trying to make an SPDX document for his offering has three
> methods available for defining external dependencies:
>
>
> - The artifactOf property on a File. However, this property is
> file-specific and does not effectively communicate the dependency on a
> package level. Must a component developer go through each file in his/her
> project and indicate which external projects it relates to? The artifactOf
> also does not communicate the exact relationship of a file to the external
> entity. Is a file a part of the target project? Generated by/from the
> target project? Something else?
> - A relationship to the SPDX document describing the target entity.
> This is the suggested alternative to artifactOf property where the target
> project has an available SPDX document. However, as most open-source
> components available today do not have published SPDX documents, the
> developer appears forced to create and publish his own document for each
> component the project depends on. This does not appear to be appropriate.
> - The current package entity seems best suited for describing a
> dependency, offering supplier, download location, homepage, license
> information, etc. Additionally, the package can already have an optional
> “described by” relationship to an external SPDX document if such document
> exists, while still providing meaningful information when it doesn’t. The
> problem with this approach is that the current spec mandates that a package
> have a “package verification code”. If each component developer produces
> his own verification code for each external package, his choice of excluded
> or included files may not agree with that of another developer(source vs.
> built artifacts, including vs. not including dependencies, etc), thus
> yielding verification codes that don’t verify anything.
>
> So instead, I propose adding an ExternalPackage entity. An
> ExternalPackage would contain only the subset of the Package attributes
> that describe the source and origin of the package. Specifically
>
> - description
> - downloadLocation
> - homepage
> - licenseDeclared
> - originator
> - packageFilename
> - checksum (of the downloaded package file)
> - supplier
> - versionInfo
> - external system identifiers (if implemented per Bill Schineller’s
> suggestion at
>
> http://wiki.spdx.org/view/Technical_Team/Minutes/2015-05-15#External_.2F_Package_Management_systems_identifiers
> ).
>
>
> If an SPDX document describing the package is available, it can be
> referenced via the “described by” relationship.
>
> I’ve documented this proposal on Bugzilla at
> https://bugs.linuxfoundation.org/show_bug.cgi?id=1298. I will put it on
> the wiki as soon as I have access to it. :-)
>
> Thanks.
>
>
>
>
>
> Yev Bronshteyn
> Senior Software Engineer
> Black Duck Software
>
>
> Black Duck Software <http://www.blackducksoftware.com/> | OpenHUB
> <https://www.openhub.net/> | OSDelivers
> <http://osdelivers.blackducksoftware.com/> | OSS Logistics
> <https://www.blackducksoftware.com/oss-logistics>
>
> <http://twitter.com/black_duck_sw>
> <https://www.linkedin.com/company/black-duck-software>
> <https://www.facebook.com/BlackDuckSoftware>
> <https://plus.google.com/+Blackducksoftware/>
> <http://www.slideshare.net/blackducksoftware>
>
> *JP Morgan Chase & Co. Hall of Innovation Inductee*
> <https://www.youtube.com/user/BlackDuckSoftware>
> <https://www.youtube.com/user/BlackDuckSoftware>
>
> _______________________________________________
> Spdx-tech mailing list
> [email protected]
> https://lists.spdx.org/mailman/listinfo/spdx-tech
>
>
--
Kate Stewart
Sr. Director of Strategic Projects, The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: [email protected]
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
