Created attachment 2582 [details] Recipe that will demonstrate the bug Using master as of 48b5ea6782ec7e9ab8f9a28438ef0ededa5fe224, if you use a package overrides as part of PACKAGE_ARCH when using the rpm backend. The override is not honored. I've attached a recipe that will produce the problem. Using the attached recipe one would expect that package-b would be have architecture of "all" in the rpm metadata, however it ends up being equal to the default. i.e. TUNE_PKGARCH This problem does not occur when using ipk. The ipk backend overrides the PACKAGE_ARCH for package-b as expected.
Created attachment 2583 [details] Attempt to fix this issue
Trouble is when you run this, you see: | DEBUG: Executing shell function BUILDSPEC | error: line 11: Only "noarch" sub-packages are supported: BuildArch: all | error: Package has no %description: test2-1.0-r0.0.all | Building target platforms: core2_32-poky-linux i.e. rpm only supports noarch subpackages.
At the very least we should put a sanity check into package_rpm so that if this scenario comes about, it will error rather than silently "work" and do the wrong thing. Once that is done, the bug can be pushed out into Future.
In the past RPM did not support generating "noarch" (equivalent to all) packages from within a spec file that had arch specific items. We should check if this is now supported and modify the spec file generated to match. If it is not supported, we'll need to generate an error or warning that something unsupported is being attempted. (The alternative implementation is to break up the packaging into multiple steps. Once for each specified arch.)
At a minimum a warning or something similar should be implemented in the RPM backend to make it clear what will happen.
I think a warning is sufficient. Two reasons below. 1) When such a rare case is encountered, just warn the user and ask him to split the recipe into multiple ones. I think it's cleaner than generating multiple rpm spec files for one recipe. 2) I searched OE and meta-openembedded repo, no such case. If we change the rpm backend logic for a case which could not be found in all our repos, isn't it a little weird?
Yi can you work on this for 3.1.
Did we ever had the warning?