| Summary: | Split PACKAGES into PACKAGES_DEV, PACKAGES_DBG and so on | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Robert Yang <liezhi.yang> |
| Component: | core | Assignee: | Robert Yang <liezhi.yang> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Undecided | CC: | bluelightning, mark.hatle, meta.mr.watcher, meta.watcher, richard.purdie, sgw |
| Version: | 1.6 | ||
| Target Milestone: | 1.6 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| See Also: | https://bugzilla.yoctoproject.org/show_bug.cgi?id=5531 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
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.
(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}" |
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.