On Tue, 2024-01-09 at 08:36 -0700, Joshua Watt wrote: > Because of the way that SPDX documents are linked together, the SPDX > creation tasks must re-run, even for ABI safe recipes. This sstatesig > change is more comprehensive version of the same fix found in [1], > which also has more information about the specific reproducer. > > In order to this to work correctly with the concept of allarch recipes, > a few changes need to be made to the SPDX creation tasks: > 1) All tasks now have stamp-extra-info on MACHINE_ARCH, which ensure > they are machine specific (but doesn't affect the actual stamp > contents) > 2) All machine specific variables are excluded from signature values > (specifically, SSTATE_PKGARCH and MACHINE_ARCH). These aren't > necessary since the tasks are now machine dependent anyway. > 3) do_create_spdx is no longer run before do_build. Practically > speaking, this means users should explicitly run `bitbake -c > create_spdx <recipe>` to generate the SPDX for a specific recipe. No > changes are needed to generate the SPDX for a complete image as the > tasks are automatically pulled in for that case, so this should not > affect very many users > > [1]: https://lists.openembedded.org/g/openembedded-core/message/192743 > > Signed-off-by: Joshua Watt <[email protected]> > --- > meta/classes/create-spdx-2.2.bbclass | 30 +++++++++++++++------ > meta/lib/oe/sstatesig.py | 6 +++++ > meta/lib/oeqa/selftest/cases/sstatetests.py | 2 ++ > 3 files changed, 30 insertions(+), 8 deletions(-)
Sadly, I'm afraid I'm not happy about this. This change forces a do_unpack in order for the SPDX task to run and they have to rerun per machine. This means that any time you switch machines, it will force everything to be unpacked again if for example you'd cleaned up TMPDIR in the meantime. The point behind sstate in the first place is to stop the system having to do large chunks of work such as unpacking or compiling. This change undermines the source extraction. I do think we're going to have to find a better way to handle this unfortunately, painful as that may be. When I suggested the machine specific stamps, I was assuming the bulk of the work was already done and could be reused but that isn't the same from what I'm seeing in the patch as it needs the unpacked data every time. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193465): https://lists.openembedded.org/g/openembedded-core/message/193465 Mute This Topic: https://lists.openembedded.org/mt/103621501/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
