7984 2015-07-09 21:04:21 +0000 RPM backend does not honor package overrides for PACKAGE_ARCH 2026-04-30 15:03:50 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment 1.8 x86 Multiple ACCEPTED Medium normal Future 1 randy.e.witt yi.zhao liezhi.yang mark.hatle mathieu.dubois-briand Qi.Chen randy.macleod richard.purdie yi.zhao --- --- No (bug/feature does not impact docs) oldest_to_newest 52263 0 2582 randy.e.witt 2015-07-09 21:04:21 +0000 Created attachment 2582 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. 52269 1 2583 richard.purdie 2015-07-10 07:57:13 +0000 Created attachment 2583 Attempt to fix this issue 52270 2 richard.purdie 2015-07-10 07:58:03 +0000 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. 52439 3 richard.purdie 2015-07-16 14:39:52 +0000 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. 52491 4 mark.hatle 2015-07-20 18:19:01 +0000 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.) 59105 5 mark.hatle 2016-02-16 15:06:03 +0000 At a minimum a warning or something similar should be implemented in the RPM backend to make it clear what will happen. 69614 6 Qi.Chen 2017-01-09 08:53:58 +0000 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? 85591 7 randy.macleod 2019-11-21 16:10:40 +0000 Yi can you work on this for 3.1. 105314 8 mathieu.dubois-briand 2026-04-30 15:03:50 +0000 Did we ever had the warning? 2582 2015-07-09 21:04:21 +0000 2015-07-09 21:04:21 +0000 Recipe that will demonstrate the bug overrides-bug.bb application/octet-stream 285 randy.e.witt U1VNTUFSWSA9ICJHZW5lcmF0ZXMgcGFja2FnZSB0byBiZSBpbnN0YWxsZWQgZnJvbSB0aGUgcGFj a2FnZSBmZWVkIgpMSUNFTlNFID0gIk1JVCIKTElDX0ZJTEVTX0NIS1NVTSA9ICJmaWxlOi8vJHtD T01NT05fTElDRU5TRV9ESVJ9L01JVDttZDU9MDgzNWFkZTY5OGUwYmNmODUwNmVjZGEyZjdiNGYz MDIiCgpBTExPV19FTVBUWV8ke1BOfSA9ICIxIgpBTExPV19FTVBUWV9wYWNrYWdlLWIgPSAiMSIK ClBBQ0tBR0VTICs9ICJwYWNrYWdlLWIiCgpQQUNLQUdFX0FSQ0hfcGFja2FnZS1iID0gImFsbCIK 2583 2015-07-10 07:57:13 +0000 2015-07-10 07:57:13 +0000 Attempt to fix this issue rpmsubarch.patch text/plain 1670 richard.purdie RnJvbSBhMzg3YWMxZjdkZjQ3NjUxNTEzNThiOGU1NzM1NDhlZDA5ZDQ4NTRmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSaWNoYXJkIFB1cmRpZSA8cmljaGFyZC5wdXJkaWVAbGludXhm b3VuZGF0aW9uLm9yZz4KRGF0ZTogVGh1LCA5IEp1bCAyMDE1IDIwOjU2OjMyICswMDAwClN1Ympl Y3Q6IHBhY2thZ2VfcnBtOiBTdXBwb3J0IGRpZmZlcmVudCBzdWIgcGFja2FnZSBhcmNoCgpTaWdu ZWQtb2ZmLWJ5OiBSaWNoYXJkIFB1cmRpZSA8cmljaGFyZC5wdXJkaWVAbGludXhmb3VuZGF0aW9u Lm9yZz4KCmRpZmYgLS1naXQgYS9tZXRhL2NsYXNzZXMvcGFja2FnZV9ycG0uYmJjbGFzcyBiL21l dGEvY2xhc3Nlcy9wYWNrYWdlX3JwbS5iYmNsYXNzCmluZGV4IDI3MWI5YWUuLjJiZWI2ZGYgMTAw NjQ0Ci0tLSBhL21ldGEvY2xhc3Nlcy9wYWNrYWdlX3JwbS5iYmNsYXNzCisrKyBiL21ldGEvY2xh c3Nlcy9wYWNrYWdlX3JwbS5iYmNsYXNzCkBAIC0yOTIsNiArMjkyLDggQEAgcHl0aG9uIHdyaXRl X3NwZWNmaWxlICgpIHsKICAgICBzcmNkZXNjcmlwdGlvbiA9IGQuZ2V0VmFyKCdERVNDUklQVElP TicsIFRydWUpIG9yICIuIgogICAgIHNyY2N1c3RvbXRhZ3NjaHVuayA9IGdldF9wYWNrYWdlX2Fk ZGl0aW9uYWxfbWV0YWRhdGEoInJwbSIsIGQpCiAKKyAgICBzcmNwa2dhcmNoID0gZC5nZXRWYXIo J1BBQ0tBR0VfQVJDSCcsIFRydWUpCisKICAgICBzcmNkZXBlbmRzICAgICA9IHN0cmlwX211bHRp bGliX2RlcHMoZC5nZXRWYXIoJ0RFUEVORFMnLCBUcnVlKSwgZCkKICAgICBzcmNyZGVwZW5kcyAg ICA9IFtdCiAgICAgc3JjcnJlY29tbWVuZHMgPSBbXQpAQCAtMzQxLDYgKzM0Myw3IEBAIHB5dGhv biB3cml0ZV9zcGVjZmlsZSAoKSB7CiAKICAgICAgICAgc3BsaXRuYW1lICAgID0gc3RyaXBfbXVs dGlsaWIocGtnbmFtZSwgZCkKIAorICAgICAgICBzcGxpdHBrZ2FyY2ggPSAobG9jYWxkYXRhLmdl dFZhcignUEFDS0FHRV9BUkNIJywgVHJ1ZSkgb3IgIi4iKQogICAgICAgICBzcGxpdHN1bW1hcnkg PSAobG9jYWxkYXRhLmdldFZhcignU1VNTUFSWScsIFRydWUpIG9yIGxvY2FsZGF0YS5nZXRWYXIo J0RFU0NSSVBUSU9OJywgVHJ1ZSkgb3IgIi4iKQogICAgICAgICBzcGxpdHZlcnNpb24gPSAobG9j YWxkYXRhLmdldFZhcignUEtHVicsIFRydWUpIG9yICIiKS5yZXBsYWNlKCctJywgJysnKQogICAg ICAgICBzcGxpdHJlbGVhc2UgPSAobG9jYWxkYXRhLmdldFZhcignUEtHUicsIFRydWUpIG9yICIi KQpAQCAtNTUwLDYgKzU1Myw4IEBAIHB5dGhvbiB3cml0ZV9zcGVjZmlsZSAoKSB7CiAKICAgICBw cmludF9kZXBzKHNyY2RlcGVuZHMsICJCdWlsZFJlcXVpcmVzIiwgc3BlY19wcmVhbWJsZV90b3As IGQpCiAgICAgcHJpbnRfZGVwcyhzcmNyZGVwZW5kcywgIlJlcXVpcmVzIiwgc3BlY19wcmVhbWJs ZV90b3AsIGQpCisgICAgaWYgc3BsaXRwa2dhcmNoICE9IHNyY3BrZ2FyY2g6CisgICAgICAgIHNw ZWNfcHJlYW1ibGVfdG9wLmFwcGVuZCgnQnVpbGRBcmNoOiAlcycgJSBzcGxpdHBrZ2FyY2gpCiAg ICAgaWYgc3JjcnByZWluc3Q6CiAgICAgICAgIHByaW50X2RlcHMoc3JjcmRlcGVuZHMsICJSZXF1 aXJlcyhwcmUpIiwgc3BlY19wcmVhbWJsZV90b3AsIGQpCiAgICAgaWYgc3JjcnBvc3RpbnN0Ogot LSAKY2dpdCB2MC4xMC4yCgo=