Packaging Committee Meeting Summary (2010-02-03)

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100208/71a5105a/attachment-0001.bin