On Thu, Jun 1, 2023 at 5:33 AM Yu, Mingli <[email protected]> wrote: > > > > On 5/30/23 23:09, Bruce Ashfield wrote: > > 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 Tue, May 30, 2023 at 10:54 AM Richard Purdie > > <[email protected]> wrote: > >> > >> On Tue, 2023-05-30 at 16:33 +0200, Alexander Kanavin wrote: > >>> I might be missing something here, but can the free-form, anonymous > >>> python code block be avoided? Don't we have PACKAGES_DYNAMIC for this > >>> purpose? > >> > >> PACKAGES_DYNAMIC is for when we can't predict the packages a recipe > >> might generate. A good example might be kernel modules. > >> > >> You're right that we could add a do_split_packages() call to the qemu > >> recipe have have it generate these dynamically. > >> > >> The downside would be the namespacing as dynamic packages need to have > >> specific namespaces (e.g. kernel-module-XXX). This means qemu-mips > >> wouldn't be an option (conflicts with non dynamic packages like qemu- > >> dbg). > >> > >> We could use a more specific prefix like qemu-system-XXX and qemu-user- > >> XXX and use do_split_packages > >> > >> I did also wonder about using more specific inline python for some of > >> this, things along the lines of: > >> > >> PACKAGES += '${@" ".join("qemu-system-" + x for x in > >> d.getVar('QEMU_TARGETS').split())}' > >> > >> I'm also not a fan of the python code block. > >> > >> We do use do_split_packages() in other recipes like gstreamer to handle > >> things like this. > >> > > > > And in case anyone hasn't looked it up, this is the meta-virt solution: > > > > https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc > > Thanks! I did see this before I send out > https://patchwork.yoctoproject.org/project/oe-core/patch/[email protected]. > > > Considering to dynamically generate the sub-packages via QEMU_TARGETS, > so I use a python block and don't need the change the code even > QEMU_TARGETS has some change.
QEMU_TARGETS is not something that changes very often. I still think that there needs to be a way to opt-out of the split packages, since there are some split requirements for virtualization, etc, that don't follow the relatively simple pattern being introduced here. With the python code and the :prepend, I don't see how I'll be able to opt out of it in meta-virtualization. Also, the dependency I see in the v2 patch isn't what I'd expect to keep existing use cases working. i.e. For kernel modules we have the package that rdepends on all the split packages, since there are expectations in places that all the qemu-system packages are installed. Bruce > > But I should let all sub-package to depend the qemu-7.2.0*.rpm. > > Thanks, > > > > > Which I'll have to re-work once (if) something lands in core. > > > > It isn't suitable as-is, but it doesn't need any python code to suit > > the on-target system emulation needs of 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 (#182106): https://lists.openembedded.org/g/openembedded-core/message/182106 Mute This Topic: https://lists.openembedded.org/mt/99219254/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
