On Sat, Feb 06, 2010 at 12:24:08AM +0100, Kevin Kofler wrote: > Paul Howarth wrote: > > Wouldn't this problem be avoided if the SRPM was built in a buildroot > > containing all of the buildreqs (like the binary RPMs are)? > > > > It would be an extra step in the build process, but not a big extra step. > > > > 1. Build SRPM in minimal buildroot to determine buildreqs (as currently) > > 2. Populate buildroot with buildreqs (as currently) > > 3. Rebuild SRPM in this buildroot (this is the extra step) > > 4. Build binary RPMs in this buildroot (as currently) > > This was discussed in the 2010-01-08 FESCo meeting (with people from rel-eng > also present). It was decided that this was not worth the effort and that > using macros in SRPMs in this way is not something we want to support. Normally automation and lack of duplication is regarded as a good thing. Package X and mingw32-X are related. The description of mingw32-X could be something like: "This package is the library X, cross-compiled for 32 bit Windows. Do NOT install this package if you want the native library X (install package 'X' instead). Install this package only if you want to cross-compile a program which uses library X." In almost any other area of computer science one would use a macro for this. RPM doesn't always expand macros in the %description section. That's a bug in RPM and/or the build system. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
