On Thu, Jun 8, 2023 at 10:01 PM Yu, Mingli <[email protected]> wrote:
> Hi Bruce, > > I didn't reply the v1 patch directly and just include the comments and > concerns when generate v2,v3,v4,v5 patch. > > I'm sorry the overrides for qemu split in meta-vir as > https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc > doesn't work if we make the qemu split change. > <https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc> > > > <https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc> > Is it okay for you to install the qemu arch rpms you need or qemu-all(if > you want all qemu binary) after the qemu split change? > <https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc> > It actually isn't that. I want a different split of the packages. But I see your v6 is using the function variable, so I'll be able to remove it from processing and restore my existing package splits. Bruce > > > <https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc> > > Thanks, > ------------------------------ > *From:* Bruce Ashfield <[email protected]> > *Sent:* Friday, June 9, 2023 00:16 > *To:* Richard Purdie <[email protected]> > *Cc:* Yu, Mingli <[email protected]>; > [email protected] < > [email protected]> > *Subject:* Re: [OE-core] [PATCH v5] qemu: Split the qemu package > > * CAUTION: This email comes from a non Wind River email account!* > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > > > On Thu, Jun 8, 2023 at 11:44 AM Richard Purdie < > [email protected]> wrote: > > On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote: > > > > > > On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie > > <[email protected]> wrote: > > > 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. > > > > > > > > > Can you think of a problem with the PACKAGESPLITFUNCS method for this > > packaging split ? > > > > At least that way I could inhibit it from my other layers, versus > > with this prepend, I don't see any options to have my own package > > splitting. > > We can do this in a PACKAGESPLITFUNCS function. I guess I'm just > nervous of having too many different ways of packaging qemu as I was > hoping we could get something which would work for all users. > > > There are some very specific use cases for virtualization, where some > separation models use different architectures for devices, even > architectures that don't match the target (host in the running system). > > There are also some combinations of usermode and system, as well as > support and firmware, etc. > > I can't see a clean/easy way to make the split being proposed here serve > all those existing (and admittedly odd) case. Having a way to override it > (even temporarily) is a better transition path for meta-virt. > > Bruce > > > > Cheers, > > Richard > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end > - "Use the force Harry" - Gandalf, Star Trek II > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182527): https://lists.openembedded.org/g/openembedded-core/message/182527 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]] -=-=-=-=-=-=-=-=-=-=-=-
