On Sun, 2010-02-07 at 22:27 +0000, Richard W.M. Jones wrote: > 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. This is kind of a bug in the build system, but it's... debatable. Here's the scenario. When submitting a build to koji, koji launches a task to construct the SRPM. This task checks out the package from CVS, downloads any additional sources from the lookaside cache, and runs rpmbuild -bs to build the SRPM. The output of this task is the SRPM, which is then handed to the per-arch build tasks as input. This task runs in a chroot. This chroot is minimal, so the only packages around to define rpm macros are redhat-rpm-config and rpm itself. rpm, unlike other string languages like make (or even Bourne shells) does not substitute empty strings for undefined macros. So if an undefined macro is present in the spec file in %description, it'll be emitted into the SRPM unexpanded. (Whether the binary RPMs emitted from the arch build tasks expand this variable depends on whether a package to expand the macro is installed, and whether that field is inherited from the SRPM or expanded from the spec file; I'm almost certain it's the latter.) You might like to install additional packages before actually running the rpmbuild -bs, but rpm has no way of expressing this kind of "SourceBuildRequires". You could add it out of band in another file in CVS, but that's unpleasant, since you'd want that metadata captured in the SRPM and it wouldn't be unless you added a SourceNNN like for it. So I mean, you could add it to redhat-rpm-config, but at least in this case I don't see a huge benefit. That kind of templating seems like it belongs in rpmdev-newspec(1). - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
