| Message ID | 20230608054525.3293334-1-mingli.yu@eng.windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v5] qemu: Split the qemu package | expand |
On Thu, Jun 8, 2023 at 1:45 AM Yu, Mingli <mingli.yu@eng.windriver.com> wrote: > > From: Mingli Yu <mingli.yu@windriver.com> > > Currently all files as below packaged into one package such as > qemu-7.2.0-*.rpm. After the qemu package installed on the target, > it will take up about 464M which includes not only the one matches > the arch of the target but aslo all available built qemu targets > which set by QEMU_TARGETS. > > # ls tmp-glibc/work/core2-64-wrs-linux/qemu/7.2.0-r0/image/usr/bin/ > qemu-aarch64 qemu-img qemu-mips64el qemu-ppc64 > qemu-sh4 qemu-system-loongarch64 qemu-system-ppc qemu-system-x86_64 > qemu-arm qemu-io qemu-mipsel qemu-ppc64le > qemu-storage-daemon qemu-system-mips qemu-system-ppc64 > qemu-x86_64 qemu-edid qemu-loongarch64 qemu-mips.real > qemu-pr-helper qemu-system-aarch64 qemu-system-mips64 > qemu-system-riscv32 qemu-ga qemu-mips qemu-nbd > qemu-riscv32 qemu-system-arm qemu-system-mips64el > qemu-system-riscv64 qemu-i386 qemu-mips64 qemu-ppc > qemu-riscv64 qemu-system-i386 qemu-system-mipsel qemu-system-sh4 > > Split the qemu package into qemu-7.2.0-*.rpm, qemu-system-*.rpm, > qemu-user-*.rpm and etc. And let user can only choose the corresponding > qemu arch package they want to install should ease the concerns who > cares much about the size in embedded device as it decreases the qemu rpm > (qemu-7.2.0*.rpm) size from about 65M to about 13M and the size of the > extracted qemu RPM decreased from about 464M to about 230M. > > For the users who want to install all arch packages, they can install > qemu-system-all and qemu-user-all to meet their need. > > Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > --- > meta/recipes-devtools/qemu/qemu.inc | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc > index a87dee5c99..367b924f9c 100644 > --- a/meta/recipes-devtools/qemu/qemu.inc > +++ b/meta/recipes-devtools/qemu/qemu.inc > @@ -230,6 +230,26 @@ INSANE_SKIP:${PN} = "arch" > > FILES:${PN} += "${datadir}/icons" > > +# For user who want to install all arch packages > +PACKAGES =+ "${PN}-system-all ${PN}-user-all" > + > +ALLOW_EMPTY:${PN}-system-all = "1" > +ALLOW_EMPTY:${PN}-user-all = "1" > + > +python populate_packages:prepend() { > + archdir = d.expand('${bindir}/') > + syspackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$', '${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True) > + if syspackages: > + d.setVar('RDEPENDS:' + d.getVar('PN') + '-system-all', ' '.join(syspackages)) > + > + userpackages = do_split_packages(d, archdir, r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$', '${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True) > + if userpackages: > + d.setVar('RDEPENDS:' + d.getVar('PN') + '-user-all', ' '.join(userpackages)) > + mipspackage = d.getVar('PN') + "-user-mips" > + if mipspackage in ' '.join(userpackages): > + d.appendVar('RDEPENDS:' + mipspackage, ' ' + d.getVar("MLPREFIX") + 'bash') > +} 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. 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. Bruce > + > # Put the guest agent in a separate package > PACKAGES =+ "${PN}-guest-agent" > SUMMARY:${PN}-guest-agent = "QEMU guest agent" > -- > 2.25.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#182494): https://lists.openembedded.org/g/openembedded-core/message/182494 > Mute This Topic: https://lists.openembedded.org/mt/99401176/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
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
On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie < richard.purdie@linuxfoundation.org> 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. Bruce > > 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 >
On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote: > > > On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie > <richard.purdie@linuxfoundation.org> 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. Cheers, Richard
On Thu, Jun 8, 2023 at 11:44 AM Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote: > > > > > > On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie > > <richard.purdie@linuxfoundation.org> 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 >
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> Thanks, ________________________________ From: Bruce Ashfield <bruce.ashfield@gmail.com> Sent: Friday, June 9, 2023 00:16 To: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Yu, Mingli <Mingli.Yu@windriver.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> 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 <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>> wrote: On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote: > > > On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie > <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>> 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
On Thu, Jun 8, 2023 at 10:01 PM Yu, Mingli <Mingli.Yu@windriver.com> 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 <bruce.ashfield@gmail.com> > *Sent:* Friday, June 9, 2023 00:16 > *To:* Richard Purdie <richard.purdie@linuxfoundation.org> > *Cc:* Yu, Mingli <Mingli.Yu@windriver.com>; > openembedded-core@lists.openembedded.org < > openembedded-core@lists.openembedded.org> > *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 < > richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote: > > > > > > On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie > > <richard.purdie@linuxfoundation.org> 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 > >
Okay, let us use v6 to track the patch. Thanks, ________________________________ From: Bruce Ashfield <bruce.ashfield@gmail.com> Sent: Friday, June 9, 2023 11:25 To: Yu, Mingli <Mingli.Yu@windriver.com> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> 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 10:01 PM Yu, Mingli <Mingli.Yu@windriver.com<mailto:Mingli.Yu@windriver.com>> 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://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$> <https://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$> 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://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$> 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://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$> Thanks, ________________________________ From: Bruce Ashfield <bruce.ashfield@gmail.com<mailto:bruce.ashfield@gmail.com>> Sent: Friday, June 9, 2023 00:16 To: Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>> Cc: Yu, Mingli <Mingli.Yu@windriver.com<mailto:Mingli.Yu@windriver.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>> 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 <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>> wrote: On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote: > > > On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie > <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>> 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
diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index a87dee5c99..367b924f9c 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -230,6 +230,26 @@ INSANE_SKIP:${PN} = "arch" FILES:${PN} += "${datadir}/icons" +# For user who want to install all arch packages +PACKAGES =+ "${PN}-system-all ${PN}-user-all" + +ALLOW_EMPTY:${PN}-system-all = "1" +ALLOW_EMPTY:${PN}-user-all = "1" + +python populate_packages:prepend() { + archdir = d.expand('${bindir}/') + syspackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$', '${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True) + if syspackages: + d.setVar('RDEPENDS:' + d.getVar('PN') + '-system-all', ' '.join(syspackages)) + + userpackages = do_split_packages(d, archdir, r'^qemu-((?!system|edid|ga|img|io|nbd|pr-helper|storage-daemon).*)$', '${PN}-user-%s', 'QEMU full user emulation binaries(%s)' , prepend=True) + if userpackages: + d.setVar('RDEPENDS:' + d.getVar('PN') + '-user-all', ' '.join(userpackages)) + mipspackage = d.getVar('PN') + "-user-mips" + if mipspackage in ' '.join(userpackages): + d.appendVar('RDEPENDS:' + mipspackage, ' ' + d.getVar("MLPREFIX") + 'bash') +} + # Put the guest agent in a separate package PACKAGES =+ "${PN}-guest-agent" SUMMARY:${PN}-guest-agent = "QEMU guest agent"