On 11/24/23 9:44 AM, Joshua Watt wrote:
While we have the information about each recipe and package that is built in the SPDX document, the process of creating the document has to happen after do_package so that we know what files are actual in each package. As such, it's not currently possible to make a SPDX "package" for each package (because do_package is over). We would also have to figure out if the SPDX packages would depend on each other to provide missing IDs (which is quite tricky) or if each package is the complete SBoM for what it is describing (which results it larger packages and many SPDX packages having the same duplicates IDs). As with many things SPDX, version 3 will probably make this a little simpler.
We can generate package specific SPDX as part of the do_package operation. What we can't do is assemble this into a filesystem knowledge.
The right way to handle a binary distribution is include the license information in the package so that it gets installed when the package gets installed. (Either directly or via an rrecommend of another license package.)
It's then up to the user to assemble the files on the running filesystem to create an overall device manifest. (Since this takes up space, it needs to continue to be something that is optional, as a large core of our users won't want this behavior -- but it is the right behavior for a dynamically updateable package based binary distribution. Once it's been updated there is no longer a 'golden' set, since the users can modify the arbitrary installed combinations of software.
--Mark
On Fri, Nov 24, 2023, 3:06 AM Michael Opdenacker <[email protected] <mailto:[email protected]>> wrote:Hi Joshua, all, (happy Thanksgiving week-end, no emergency) On 22.11.23 at 21:04, Michael Opdenacker via lists.openembedded.org <http://lists.openembedded.org> wrote: > Available reference binary artifacts > ------------------------------------ > > The first prototype will make the below binary artifacts publicly > available: > > - Root filesystem images (as specified above) > > - Binary package feeds (as specified above) > > - PR (https://docs.yoctoproject.org/ref-manual/variables.html#term-PR <https://docs.yoctoproject.org/ref-manual/variables.html#term-PR>) > database, so that people can manage updates to packages, by > importing the > database in a local PR server. > > - Prebuilt object data ("Shared State cache) through a public server > (see > https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS <https://docs.yoctoproject.org/ref-manual/variables.html#term-SSTATE_MIRRORS>), > to reuse binary output already built by the Yocto Project > autobuilders, to > reduce the compile time of additional packages. > > - Hash Equivalence data through a public server > (see > https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM <https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_HASHSERVE_UPSTREAM>), > to increase the reusability of prebuilt objects. I realize I completely overlooked the need to supply SPDX information. While we can ship an SPDX description of the initial images, how can we produce an update of this description after we install extra packages or update existing ones through the binary package feeds? Should the build system also generate "-spdx" packages for each component? Cheers Michael.-- Michael Opdenacker, BootlinEmbedded Linux and Kernel engineering https://bootlin.com <https://bootlin.com>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1860): https://lists.openembedded.org/g/openembedded-architecture/message/1860 Mute This Topic: https://lists.openembedded.org/mt/102755562/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
