Created attachment 807930 [details] spec file for zlib-1.2.3-7.el5 to replicate the problem. Description of problem: I discovered that the arch of a sub-package can radically alter the behavior of rpmbuild. As background, I am rebuilding a custom ruby for RHEL5 and the ruby interpreter itself is arch specific. However, the various gems that come with it are NOT - they are text files. So I tagged these sub packages as 'noarch'. The fact that there are a few noarch packages prevented the generation of a %{name}-debuginfo rpm. This resulted in my build having many 'installed but unpackaged' files - all of them debuginfo. Version-Release number of selected component (if applicable): rpm-4.4.2.3-34.el5 How reproducible: 100% Steps to Reproduce: 1. Add a noarch subpackage to a package with binaries 2. try to build 3. 'installed but unpackaged debuginfo' Actual results: binaries are stripped but no debuginfo package is generated Expected results: attributes of a sub-package should not override the logic of the main package. I should be able to classify non-arch specific packages as noarch even if I've built some arch specific stuff. Additional info: Looks like this came up in bug 227790 where it was declared not a bug. Yet in RHEL6, I can perform this behavior. I've attached a slightly modified 'zlib' spec file you can use to replicate the behavior.
(In reply to jcpunk from comment #0) > Additional info: > Looks like this came up in bug 227790 where it was declared not a bug. Yet > in RHEL6, I can perform this behavior. Well, RHEL-6 has a much newer rpm version too, support for noarch-subpackages was only added in rpm >= 4.6.0. Feature backports are no longer considered at this point of RHEL-5 life-cycle. That RHEL-5 rpm does not cleanly error out on the unsupported construct could be considered a bug, but it's hardly critical enough to warrant a fix at this point either, sorry.