On Thu, 2023-06-08 at 09:33 -0400, Bruce Ashfield wrote: > At this point, you can probably see why I ended up using the explicit > variables and overrides versus python when doing the > meta-virtualization splits. :) > > I have a few more comments that I made in v1, that I haven't seen > directly handled or replied to. > > My only remaining concern (and it may just be my own concern), is that > there's no way to change this packaging split. Either you take the > programatic split, or you take the -all packages. > > Other packages (glibc, kernel-modules) have a variable that controls > whether the split happens or not, I'd like to see something similar > here .. but I do realize that it makes test complexity more, and that > Richard normally doesn't like conditionals like that.
I only "like" conditionals if it is a code path that will be well travelled, otherwise we tend to find one of the paths is broken. I don't think we need to make this conditional. > Alternatively, did we rule out using PACKAGESPLITFUNCS to add the > splitting routine ? With that, we could remove the processing in > places we don't want it, in particular for the native/sdk builds, as I > found that we really don't want the splitting of qemu in those > scenarios. FWIW, native isn't packaged so that one at least isn't a problem! I'm assuming the "all" package can be used in the SDK contexts easily enough to get the needed behaviour there? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182510): https://lists.openembedded.org/g/openembedded-core/message/182510 Mute This Topic: https://lists.openembedded.org/mt/99401176/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
