Hide Forgot
Description of problem: I was testing file bz712992 and I have realized that noarch package built without the --target noarch option is not noarch but inherits the arch from the system where it has been built. Well, such an RPM can be installed on any other arch (it is in fact noarch), just the bytes in the header says something different. file command reads the architecture from the RPM file header, in particular it is the fifth column in RPM hexdump (http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html): TRUE noarch is 'ff00': # hexdump dummy-1.0-1.noarch.rpm | head -n 1 0000000 abed dbee 0003 0000 ff00 7564 6d6d 2d79 # file dummy-1.0-1.noarch.rpmdummy-1.0-1.noarch.rpm: RPM v3.0 bin noarch FAKE noarch is not 'ff00' but e.g. '0100': # cat dummy.spec Summary: dummy Package Name: dummy Version: 1.0 Release: 1 Group: System Environment/Base License: GPL BuildArch: noarch Provides: dummy %description This is a dummy test package created by make_dummy_package.sh script %files # rpmbuild -bb dummy.spec Processing files: dummy-1.0-1.noarch Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/dummy-1.0-1.x86_64 Wrote: /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.ieAQxD + umask 022 + cd /root/rpmbuild/BUILD + /bin/rm -rf /root/rpmbuild/BUILDROOT/dummy-1.0-1.x86_64 + exit 0 # hexdump /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm | head -n 1 0000000 abed dbee 0003 0000 0100 7564 6d6d 2d79 # file /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm: RPM v3.0 bin i386/x86_64 Version-Release number of selected component (if applicable): rpm-4.8.0-16.el6.x86_64 How reproducible: always Steps to Reproduce: see above Required behavior: rpmbuild -bb noarch.spec should built noarch package with correct bytes (ff00) in the RPM header.
If you read the rpm file format document further, you'll encounter a section called "The lead: An Abandoned Data Structure". It was already considered dead and unused back when the venerable max-rpm was written, in other words more than a decade ago. This can only be considered a bug in the spirit of "be conservative what you do, be liberal what you accept" really, the data from the lead section of rpm should not be used and cannot be trusted to be correct or even present (it might even be all zeroes except for the "magic" part). I also suspect this issue itself is over ten years old, meaning practically every single noarch rpm in the wild has a wrong architecture in the lead. Fixing this would be easy, but it doesn't change the fact that you cannot trust the data from the lead. If libmagic wants to figure out more data from rpms, it should use parse the data from the header, not the lead.