Bug 14492

On first run, the kernel module is not built.  So I triggered it using:

bitbake hello-mod

and it still fail on rootfs generation. oe-pkgdata-util has:

% oe-pkgdata-util package-info kernel-module-hello                                                                                         kernel-module-hello is in the RPROVIDES of kernel-module-hello-5.4.126+ga402819056e6:
kernel-module-hello 0.1-r0 hello-mod 0.1-r0 3008

I understand that BitBake cannot infer that kernel-module-hello will be built, so it cannot add the rprovides to the metadata automatically however once the hello-mod recipe is built it does know it.

I tried multiple things:

  - PROVIDES += "kernel-module-hello"
  - PACKAGES_DYNAMIC = "^kernel-module-hello$"

and I could only proceed adding it to the RPROVIDES_${PN} list. This seems like a bug to me and I'd like to understand what is going on here.

Created attachment 4817 [details]
Screenshot of error

Alex - This does look a bit like an opkg issue. Could you have a look at the attached screenshot as it shows the opkg command and the fact the package has an RPROVIDES that should mean opkg should install it, at least as I understand things.

That certainly seems concerning. I should have some time to take a look at it this weekend.

Interesting that it bares some superficial similarities to opkg bug 11459.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14459

I was able to reproduce the do_rootfs error here, using the diff that Otavio posted. When the `core-image-minimal` recipe is building its rootfs, it first populates a recipe-specific package feed at...

`build:tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0-r0/oe-rootfs-repo`

... to-which the create_packages_dir() method [1] will copy all IPKs which are owned by recipes *which are task-dependencies of the core-image-minimal.do_rootfs` task*.

When you removed the `RPROVIDES:${PN}` line, it broke the task dependecy with the core image. And neither the PACKAGES_DYNAMIC, nor IMAGE_INSTALL variables asserts a task dependency in its place. So the `hello-mod` IPKs are never added to the recipe-specific dir, and opkg is unaware of them at install time.

You can interrogate the `core-image-minimal` dependencies using `bitbake -g`.

So this isn't an opkg bug, since the IPK is never gets that far. I'll move this bug back to OE, since there is an argument to be made that IMAGE_INSTALL should be more intelligent about adding do_rootfs dependencies.

[1] https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n451

(In reply to comment #6)
> I was able to reproduce the do_rootfs error here, using the diff that Otavio
> posted. When the `core-image-minimal` recipe is building its rootfs, it
> first populates a recipe-specific package feed at...
> 
> `build:tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0-r0/oe-
> rootfs-repo`
> 
> ... to-which the create_packages_dir() method [1] will copy all IPKs which
> are owned by recipes *which are task-dependencies of the
> core-image-minimal.do_rootfs` task*.
> 
> When you removed the `RPROVIDES:${PN}` line, it broke the task dependecy
> with the core image. And neither the PACKAGES_DYNAMIC, nor IMAGE_INSTALL
> variables asserts a task dependency in its place. So the `hello-mod` IPKs
> are never added to the recipe-specific dir, and opkg is unaware of them at
> install time.

Thanks for debugging that and sorry it turned out to be an OE-Core issue. It certainly makes more sense now, I was rather worried it was an opkg issue similar to that other reported bug.

The trouble now is I don't know how we can have bitbake know to get "kernel-module-hello" from hello-mod instead of the default kernel, or even how to make it clear to the user there is a potential issue...

Using the generated package name isn't a possibility?

(In reply to comment #8)
> Using the generated package name isn't a possibility?

No, the task graph can't use generated information.

I think it's interesting that `RPROVIDES` *does* add a task dependency to the image recipe, and also that `PROVIDES` does not (in both my and Otavio's testing).

AFAIK, the only breadcrumb which connects the image and module recipes is IMAGE_INSTALL - so it seems like *something* is doing a reverse lookup based on the package name. Maybe the next step is to trace down that codepath and see if we're doing something wacky, or if it can service as the basis for a better solution.

Zhe, can you try to find time for this in the coming month or so?
I'm not sure if it's still a problem.