| Summary: | It is possible to specify a PACKAGE and a PKG_ rename that conflict | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Mark Hatle <mark.hatle> | ||||
| Component: | core | Assignee: | Fawzi KHABER <fawzi.khaber> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | Medium+ | CC: | fawzi.khaber, kai.kang, maxin.john, meta.mr.watcher, meta.watcher, randy.macleod, yoann.congal | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 4.2 M4 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
Created attachment 4934 [details]
log
While trying to reproduce the bug, it seems like in recent version, it is not possible to use PACKAGES and PKG_ to set a name conflict, As it throws :
line 61: %package -n <name>: package <name> already exists
This should be resolved ?
ping a simple recipe to test package rename
LICENSE = "closed"
PACKAGES += "bot"
PKG:${PN}-dev = "bot"
@Fawzi, reading the commit that removed the conflict in libmtp [1], we can see that we still have the same error. As suggested by Mark Hatle, I think we should at least warn (if not error) when this case arises. 1: https://github.com/openembedded/meta-openembedded/commit/51c3205dc838e9365b2b16a20e133f2c9b32a002 |
It is possible to specify both a PACKAGE and PKG_ that conflict, the libmtp within meta-openembedded is doing this. The key code is: PACKAGES =+ "libmtp-common libmtp-runtime mtp-tools" RDEPENDS_${PN} += "libmtp-common" RRECOMMENDS_${PN} += "libmtp-runtime mtp-tools" FILES_${PN}-dbg += "${nonarch_base_libdir}/udev/.debug/*" PKG_${PN}-bin = "mtp-tools" SUMMARY_${PN}-bin = "Tools for communicating with MTP devices" The package '${PN}-bin' is being renmaed by the PKG_${PN}-bin to be 'mtp-tools', but mtp-tools already exists in the PACKAGES variable. This same type of problem could occur via an automatic rename (such as the debian.bbclass). A package qa of some sort is needed to look for this and error before it produces a packaging error (this fails with RPM) or an indeterminate behavior.