On Fri, Nov 24, 2023 at 8:31 AM Joshua Watt <[email protected]> wrote:
> > > On Fri, Nov 24, 2023, 8:53 AM Mark Hatle <[email protected]> > wrote: > >> >> >> 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. >> > > Are you taking about just the SPDX licensing information, or full SPDX? I > was talking about the latter, and it's not as trivial to do that in > do_package for a number of reasons > > > >> 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.) > > Spdx info is more than license it’s something like src package I am not sure if we really need to install this into images by default but the feeds should be available to do so > >> >> 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, Bootlin >> > Embedded Linux and Kernel engineering >> > https://bootlin.com <https://bootlin.com> >> > >> > >> > >> > >> > >> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1864): https://lists.openembedded.org/g/openembedded-architecture/message/1864 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]] -=-=-=-=-=-=-=-=-=-=-=-
