At the moment if your recipe produces no main (${PN}) package because it ends up empty then because of the RDEPENDS_${PN}-dev dependency on the ${PN} package, the ${PN}-dev package is unusable (and ${PN}-staticdev as well which depends upon the ${PN}-dev) because the dependency can never be satisfied. This situation can happen if your recipe only produces a static library for example. Perhaps we could change the RDEPENDS to an RRECOMMENDS to avoid this?
Richard's idea: Let's split the bug to make it more easy to solve in steps. First step : add a QA check for this case : a -dev package depending on a non-existent main package.
I would happily work on this one. Is this issue solved by the commit ddbd90a37c7e9089aaeccb42dd008cf47594099b ?
Add Richard. Please reply to the previous comment/question.
ping.
Sent a RFC patch about this bug : https://lists.openembedded.org/g/openembedded-core/topic/rfc_patch_0_2_handling_of/97195657
I put some information about this into an oe-arch email: https://lists.openembedded.org/g/openembedded-architecture/message/1701
On #8222: Comment 7 Richard Purdie 2023-09-14 15:24:57 UTC > I was asked about the status of this. I don't think there were objections to what I proposed in the email so I'd suggest we proceed in that direction. Since #8222 looks like a more narrow case than this bug. I'll work on this one and #8222 may be fixed in the process (?) The plan proposed by Richard is: a) Add warnings for dependencies (RDEPENDS or RRECOMMENDS) on packages which don't get created for some reason (either not in PACKAGES or not ALLOW_EMPTY). We should be able to properly check this using packagedata which never used to exist as it does now when these bugs were first created! We can leave the warnings disabled at first until we clean things up for core and our key layers b) Work through those warnings to work out if we can silence them at source. I think the dependency creation code for -dbg and -dev packages will need to be taught to check if a target dependency exists to fix the bulk of them. c) Explore whether we should drop PN from PACKAGES in some of the above cases. d) Explore whether we can replace the current generic RRECOMMENDS from PN-dev -> PN with something autogenerated based on the presence of shared libs e) For a long time I've wondered if we should split the -dbg packages from one per recipe to one per package with binaries in it. This would solve some of the problems that we'll likely encounter in b) but might
Patch v1 sent for part a): [PATCH 0/2] Empty packages and bogus dependencies (Part 1) https://lists.openembedded.org/g/openembedded-core/message/188381 [PATCH 1/2] insane: Add QA check for RRECOMMENDS on non-existent packages https://lists.openembedded.org/g/openembedded-core/message/188382 [PATCH 2/2] meta/recipes: Remove empty ${PN}/DEV_PKG_DEPENDENCY workarounds https://lists.openembedded.org/g/openembedded-core/message/188383
Example of a -dev only recipe in meta-oe https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/opencl/opencl-clhpp_git.bb#n22 with a workaround : # Headers only so PN is empty RDEPENDS:${PN}-dev = ""
(Picking this subject up again) (In reply to Yoann Congal from comment #8) > Patch v1 sent for part a): > [PATCH 0/2] Empty packages and bogus dependencies (Part 1) > https://lists.openembedded.org/g/openembedded-core/message/188381 > [PATCH 1/2] insane: Add QA check for RRECOMMENDS on non-existent packages > https://lists.openembedded.org/g/openembedded-core/message/188382 > [PATCH 2/2] meta/recipes: Remove empty ${PN}/DEV_PKG_DEPENDENCY workarounds > https://lists.openembedded.org/g/openembedded-core/message/188383 Those v1 patches were not merged: See RP's review: https://lists.openembedded.org/g/openembedded-core/topic/101647340#msg190796
Bulk move to 5.3
Bulk move to 6.0 M1
(Unassigning myself since a do not realistically have the time to work on this)
Bulk move of 6.0 Medium bugs to 6.1.