I would think an example with Docker – which is more cross-platform and ubiquitous might be preferable, no? Additionally, the tutorial you included would not demonstrate the creation of descendant images or the use of external references to Docker hub or any other container registry.
A more illustrative tutorial might be this: https://docs.docker.com/engine/getstarted/step_four/. Here, an image is taken from the Docker hub. Then, a descendant image is built (DESCENDANT_OF relationship to the source image) and an OSS package is added to that image (image package has CONTAINS relationship to the fortunate package). Finally, a container is created from the latter image (has a DESCENDANT_OF relationship to the latter image). This is a perfect test case. Actually, this example raises another interesting question: the source image pulled from the Docker hub is not one with a specific tag, but latest. So how would this map to a packager versionInfo? If a container is created from the descendant image a year after its descendent image is created, it will certainly use a different version of the underlying Ubuntu image than a container that’s created immediately after the descendent image. So I think we need to establish a convention that for container images, the absence of a package version should be assumed to correspond to the latest version. The alternative would be to consider latest as a version in and of itself, which seems like a horrible thing given the fluidity of what the latest version actually is. From: Kate Stewart <[email protected]> Date: Friday, October 7, 2016 at 2:27 AM To: Yev Bronshteyn <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: SPDX to describe containers? 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]<mailto:[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? [id:[email protected]] Yev Bronshteyn Senior Software Engineer E: [email protected]<mailto:[email protected]> blackducksoftware.com<https://www.blackducksoftware.com/> _______________________________________________ Spdx-tech mailing list [email protected]<mailto:[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]<mailto:[email protected]>
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
