Re: [OE-core] [PATCH 1/1] image.bbclass: deltask do_packagedata

["Denys Dmytriyenko" <denis@denix.org>]

On Fri, Mar 12, 2021 at 12:17:08PM +0100, Martin Jansa wrote:
> On Fri, Mar 12, 2021 at 03:59:20PM +0800, Robert Yang wrote:
> > Hi RP,
> > 
> > On 3/11/21 10:38 PM, Richard Purdie wrote:
> > > On Thu, 2021-03-11 at 10:02 +0100, Martin Jansa wrote:
> > > > On Thu, Mar 11, 2021 at 12:46:22AM -0800, Robert Yang wrote:
> > > > > This can fix a do_package error when compile with meta-secure-core layer:
> > > > > http://layers.openembedded.org/layerindex/branch/master/layer/meta-secure-core/
> > > > > 
> > > > > $ bitbake kernel-initramfs
> > > > > [snip]
> > > > > WARNING:kernel-initramfs-1.0-r0 do_package: Manifest
> > > > > build/tmp-glibc/sstate-control/manifest-x86_64_x86_64-nativesdk-secure-core-image-initramfs.packagedata
> > > > > not found in intel_x86_64 corei7-64 core2-64 x86_64 allarch x86_64_x86_64-nativesdk (variant '')?
> > > > > [snip]
> > > > > 
> > > > > This is because kernel-initramfs wants to pack an initramfs image into
> > > > > kernel-initramfs.rpm which adds a dependency in kernel-initramfs.bb to do this:
> > > > > 
> > > > > d.appendVarFlag('do_install', 'depends', ' ${INITRAMFS_IMAGE}:do_image_complete')
> > > > > 
> > > > > This causes kernel-initramfs' do_package depends on
> > > > > ${INITRAMFS_IMAGE}:do_image_complete's do_packagedata, then we will get the
> > > > > error. Delete do_packagedata as other do_package relelated tasks for the image
> > > > > recipe will fix the error.
> > > > > 
> > > > > Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> > > > 
> > > > Acked-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > > 
> > > > I went a bit further and inheritted nopackages, but RP mentioned that it
> > > > might be removing too much. Nothing failed with nopackages over night,
> > > > but still this smaller version will be safer as this needs to got to
> > > > gatesgarth and dunfell as well now.
> > > 
> > > This has side effects and there was a reason this wasn't done originally. The
> > > trouble is that nobody is testing for that, just wanting to fix the problem
> > > they see. To prove this isn't straightforward, I tested this locally, comparing
> > > task-depends.dot from "bitbake core-image-sato -g" before and after this patch.
> > 
> > If we want to avoid disconnecting them, it seems that a better way is fixing
> > this in the recipes which has this problem? For example, I got this error in
> > secure-core-image-initramfs.bb, then we can add "deltask do_packagedata" in the
> > recipe to fix the problem.
> 
> That's what I did in initramfs-android-image (which was triggering this
> for me as reported on ML)
> https://github.com/shr-distribution/meta-smartphone/commit/732dd29325d882a9b3414764ad4c7a254dae3f03

The issue of doing this in each and every possible initramfs image recipe is 
that it does not scale. For example, this code in the original patch is very 
common:

d.appendVarFlag('do_install', 'depends', ' ${INITRAMFS_IMAGE}:do_image_complete')

And INITRAMFS_IMAGE can be set anywhere - in machine config, distro config or 
even by end user in local.conf


> > @Martin maybe we shouldn't backport this patch to gatesgarth or dunfell since
> > it may suprise the users.
> 
> Unfortunately
> https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=e0c1db170fdd6c1d78fdfce017feae26c96fac29
> was already backported to both gatesgarth and dunfell.

Yeah, it's unfortunate. Our LTS maintainer is too good! :)
Seriously though, not sure why changing warning to error was even considered 
for backporting to LTS! Making things stricter doesn't usually fall under 
"bugfix" category...

-- 
Denys