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.) > > 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 (#1863): https://lists.openembedded.org/g/openembedded-architecture/message/1863 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]] -=-=-=-=-=-=-=-=-=-=-=-
