Hi Yev,
Great topic for discussion and figuring out best practices for
relationships. :-)
To make sure we figure this out properly, lets turn this into a
concrete example (ie. specific images and applications)
and explore the relationships that way, rather than at the abstract level.
If we get it right, with specific names,
we should then be able to take it to the abstract. You're started to go
this route with your ubuntu reference,
so how about we take what's descibed on
https://linuxcontainers.org/lxc/getting-started/ and start mapping out what
we agree as best practices for the relationships being described there?
I know some of the developers, and when we've got it mapped out, we can
cross check our understanding matches
theirs?
Kate
On Thu, Oct 6, 2016 at 5:06 PM, Yev Bronshteyn <
[email protected]> wrote:
> Hi, all,
>
>
>
> After the bake-off, I got to thinking: it could be a very strong selling
> point if SPDX could be used to describe containers. I’d like to write up
> the idea as a blog post and, perhaps, a candidate for best practices, but
> first I wanted to check if anyone here had any objections to the following
> approach.
>
>
>
> There are two packages describing a container – the CONTAINER package and
> the CONTAINER_IMAGE package.
>
>
>
> Their relationships are as follows.
>
> · DESCENDANT_OF to the package documenting the container image.
> The image package may, but does not have to have the ANCESTOR_OF
> relationship to the container package
>
> · CONTAINS to every other package deployed on the container.
> Packages deployed to the container can, but do not have to, have a
> CONTAINED_BY to the container package.
>
> · If SPDXRef-CONTAINER_IMAGE_B is created by building a container
> from SPDXRef-CONTAINER_IMAGE_A, making changes, and saving it as a new
> image, then SPDXRef-CONTAINER_IMAGE_B has a DESCENDANT_OF relationship to
> SPDXRef-CONTAINER_IMAGE_A, and SPDXRef-CONTAINER_IMAGE_A may, but doesn’t
> have to, have an ANCESTOR_OF relationship to SPDXRef-CONTAINER_IMAGE_B.
>
>
>
> Additionally, if the image from which the container is built is found on
> Docker hub, the image package would have the following external reference:
>
>
>
> Category: OTHER
>
> Type: https://hub.docker.com
>
> Identifier: name:tag, e.g. ubuntu:16.10
>
>
>
> Lastly, there’s a question is how do we identify a package or a container
> as such.
>
>
>
> One way, staying within the current spec, is to give them more specific
> SPDX identifiers. So a container package would be
> SPDXRef-CONTAINER-MyUbuntuContainer.
> The container image package that it would reference would be
> SPDXRef-CONTAINER_IMAGE_Ubuntu_16_10 (which, hopefully, would be in an
> SPDX document Canonical would publish together with its container).
>
>
>
> I don’t believe we should add any additional spec constructs to support
> containers, because we don’t want to establish the practice of growing the
> spec for every hot new way to bundle software or maintain another
> Appendix/list of package types. And, since we’re trying to get distribution
> vendors to adopt SPDX and many produce container images for their distros,
> it might make sense to work out this story well before we rev another
> version of the spec.
>
>
>
> Thoughts?
>
>
>
>
>
> [image: cid:[email protected]]
> Yev Bronshteyn
> Senior Software Engineer
> E: [email protected]
> blackducksoftware.com <https://www.blackducksoftware.com/>
>
>
>
> _______________________________________________
> Spdx-tech mailing list
> [email protected]
> https://lists.spdx.org/mailman/listinfo/spdx-tech
>
>
--
Kate Stewart
Sr. Director of Strategic Programs, 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
