I think you missed the point slightly here. Dimi does not want multiple builds, and there are not multiple architectures from the build script's viewpoint. There is only one build step, and it has one target platform, i.e. "i386". It's just that the packager happens to know that during this build with "i386" target, "make" or whatever will also produce some files that aren't strictly speaking specific to i386 - they are just plaintext files or whatever. If the package is built with, say, target "ppc" later on, these particular files will be exactly the same as for i386. So wouldn't it be nice to be able to put these files in a separate subpackage marked with "noarch", instead of having both "i386" and "ppc" packages containing identical files?Hi folks, I have a basic foo-1.0.src.rpm, and I need to be able to generate a bunch of noarch packages (Java stuff), and one .i386.rpm for some native support libs. I use BuildArch: noarch, but this results in _all_ subpackages to be noarch, I can't force one of them to be i386 :( Question is, can this be done cleanly?All depends on what you mean by "cleanly". You -- and you alone -- know that.Meanwhile, rpm has only a single build, there ain't no such thing as a sub-package build.One statically valued arch per build, please, is/was a perfectly sensible design rule.
You can of course hack up your foo.spec file to do
%ifarch noarch
<recipe for building a noarch package>
I don't think this recipe exists. Noarch build is a null command.
%else
<recipe for building the rest>
This on the other hand, will implicitly also produce the "noarch" stuff.
%endif
and then invoke
rpmbuild -ba --target=i386,noarch
to generate both noarch and non-noarch packages from a single foo.spec
- T