Jeff Johnson wrote:
On Mon, Feb 07, 2005 at 10:34:31AM +0100, Toralf Lund wrote:
Jeff Johnson wrote:
Yes, you said that already. What I had in mind, however, was something
that would essentially cause rpmbuild to re-exec itself as "rpmbuild
--target <something>" when no --target option was passed already - where
"<something>" would be the value of a tag or macro, and might contain
more than one target. This wouldn't break with the design, I think, or
at least not more than the support for multiple targets in --target
does. It may be undesirable for other reasons, though, like simplicity
(or the lack thereof.)
Forgot to answer this one earlier... (Not sure if anyone would notice it
now...)
Why does rpmbuild need changing?
Is the following script snippet that hard to write?
for arch in A B C D; do
rpmbuild -ba --target $arch foo.spec
done
No, it's not hard to write. The question is, do I want to write it? I
think it should always be a goal to encode *all* information necessary
to build a package (or set of packages) the right way in the .spec file.
Why that is a Good Thing is quite obvious, isn't it?
Loop on the build, either external to rpmbuild, or with --target
if you must. External loop is perhaps more flexibly configured
than the internal --target loop.
I may be on the wrong track here, though. What I really want to do, is
to add different archs to different %packages built from the same spec
file. That's also in some ways in conflict with the design goal stated
above, but I really only want one architecture *for the build* - I just
happen to know that some of the packages aren't really affected by the
build architecture at all (e.g. because they contain plain-text files
only), or their architecture may be "reduced" to a more basic version,
like i386 when building for i686 (because some or the files output by an
i686 build will actually be compatible with all i386 variants.)
So modify the snippet above and use common tools to change
values in *.spec. The shell is your friend, thou shall fear
no evil in valley.sh. ;-)
What exactly is the problem you are trying to solve?
I have an rpm build setup for ix86 systems where I *know* that some of
the files will be compatible with all ix86 variants regardless of the
target setting, while others will actually be target-specific, i.e. if
target is, say, i686, the files are *only* compatible with i686. I
simply want to group the files in sub packages with architecture
settings that reflect the actual install system compatibility, i.e.
package the "compatible" files in an i386 package, and the
target-specific ones in e.g. an i686 package. The point is to get one
shared rpm for the "shareable" files, and one for each target for the
others, after a multi-target build.
- T
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
