Source RPM packages -- SRPMs -- have an architecture of "src". In other words, a source RPM is a source RPM, with no architecture associated with it. There's an assumption that the package is architecture-neutral in source form, and only become architecture-specific when built into a binary RPM (unless it builds into a "noarch" RPM, which is the case with scripts, fonts, graphics, and data files).
An SRPM contains source code (typically a tarball, and sometimes patch files) and a spec file which serves as manifest and build-recipe, plus metadata generated from the spec file when the SRPM is built -- including dependencies (which, unlike binary RPMs, are actually the build dependencies).
However, the build dependencies may vary by platform. If package foo is built against bar and baz, and baz exists on some architectures but not others, then the spec file may be written to build without baz (and the accompanying features that baz enables) on some architectures. The corresponding BuildRequires lines will also be made conditional on the architecture -- and this make total sense. However, querying an SRPM on a given platform may give incorrect build dependency information for that platform if the SRPM was built on another platform -- and only rebuilding the SRPM on the target arch will correct the rpm metadata (and possibly render it incorrect for other platforms). Thus, I've come to realize, SRPMs are not truly architecture-neutral -- and I'm not sure if all our tools take this into consideration.
Edit: I know that not all of our tools take this into consideration.
Actually the src.rpm header is always arch-dependent - the architecture of an src.rpm is NOT 'src', but the architecture that src.rpm was built on. It's just that the rpmbuild and various other related tools essentially "lie" about this by replacing it with 'src' in various user-visible places.
Besides arch-conditional build-requires, macros in build-requires can and often do lead to arch-specific requirements in the src.rpm.
And even the src.rpm contents can be arch-dependent. For example arch-conditionalized sources and patches. This is (obviously) a bad practise, but technically perfectly legal and can be seen in the wild now and then:
Conditional sources are horrific -- arguably, the use of source/application of patches should be conditional, but the inclusion of those files in the srpm should not be. But yes, the tools support this practice
Let me clarify last facetweet+: I'm specifically wondering about the 25/10 DSL service. I know Teksavvy is awesome :-)3 weeks ago
18th birthday for youngest daughter yesterday. Proud of you, Laura!3 weeks ago
Anyone have comments on TekSavvy (via Bell) DSL 25Mbps down/10Mbps up service?3 weeks ago
These are my first two books: X Power Tools, a thorough guide to the X Window System (O'Reilly, ISBN 9780596101954) and Fedora Linux: A Complete Guide to Red Hat's Community Distro, a practical hands-on book on Fedora (O'Reilly, ISBN 9780596526825).
Fedora Linux is also available for online reading through Safari and in downloadable PDF format from oreilly.com