5529 2013-11-14 08:35:56 +0000 Split PACKAGES into PACKAGES_DEV, PACKAGES_DBG and so on 2013-11-15 01:58:18 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.6 x86 Multiple RESOLVED INVALID https://bugzilla.yoctoproject.org/show_bug.cgi?id=5531 Undecided enhancement 1.6 M3 1 liezhi.yang liezhi.yang bluelightning mark.hatle meta.mr.watcher meta.watcher richard.purdie sgw --- --- Yes (doc changes required) oldest_to_newest 38760 0 liezhi.yang 2013-11-14 08:35:56 +0000 The PACKAGES which is defined in the recipe often contains more than the recipe really generates, for example: $ PACKAGES="dhcp-dbg dhcp-staticdev dhcp-dev dhcp-doc dhcp-locale dhcp dhcp-server dhcp-server-config dhcp-client dhcp-relay dhcp-omshell" Note, there is a dhcp in the PACKAGES, but there is no dhcp.rpm after the build, this is because we have used += in dhcp.inc PACKAGES += "dhcp-server dhcp-server-config dhcp-client dhcp-relay dhcp-omshell" We can use PACKAGES = "dhcp-xxx dhcp-dbg dhcp-dev" to fix the problem, but this is inconvenience since a lot of recipes may have the smimilar issue, a potential fix should be: 1) Split PACKAGES into PACKAGES_DEV, PACKAGES_DBG, PACKAGES_STATICDEV and so on. 2) Default: PACKAGES = PN PACKAGES_DEV = PN-dev PACKAGES_DBG = PN-dbg ... PACKAGES += PACKAGES_DEV + PACKAGES_DBG + ... So that we can keep the back compatiblilty, and the user can reset the PACKAGES easily. 38788 1 bluelightning 2013-11-14 16:02:25 +0000 I think this is a problem of the dhcp recipe rather than a general issue to be solved. The dhcp recipe should probably be providing a dhcp package that installs something useful - if that's one or more of the other packages being added then we should set RDEPENDS_${PN}/RRECOMMENDS_${PN} and ALLOW_EMPTY_${PN} there as appropriate. In terms of having a mechanism to easily add additional packages, we have PACKAGE_BEFORE_PN for just this purpose. Accordingly I'm marking this as invalid. 38808 2 liezhi.yang 2013-11-15 01:58:18 +0000 (In reply to comment #1) > I think this is a problem of the dhcp recipe rather than a general issue to > be solved. The dhcp recipe should probably be providing a dhcp package that > installs something useful - if that's one or more of the other packages > being added then we should set RDEPENDS_${PN}/RRECOMMENDS_${PN} and > ALLOW_EMPTY_${PN} there as appropriate. > > In terms of having a mechanism to easily add additional packages, we have > PACKAGE_BEFORE_PN for just this purpose. > > Accordingly I'm marking this as invalid. Hi Paul, Thanks, do we require each recipe generates a PN named binary package in most of the cases ? Can we add a QA check for this to avoid the problem like dhcp has ? The PACKAGE_BEFORE_PN is helpful: PACKAGE_BEFORE_PN ?= "" PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}" Maybe we can adjust its defination a little, set the PACKAGE_BEFORE_PN's default value to ${PN} so that we can easily remove the ${PN} from PACKAGES. PACKAGE_BEFORE_PN ?= "${PN}" PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN}"