Jeff Johnson wrote:
> Increasingly I'm seeing spec file recipes (and rpmbuild) used in
> complicated ways.
> rpm spec file recipes contain "known good" (at least wrto rpmbuild
> content that results in successful builds and binary packages to be
> That was the whole design goal behind rpmbuild's "reproducible
> builds" for OSS.
I've seen the same kind of "abuse" with port file recipes (and Tcl)
And if the recipes were using say XML (for metadata) and Python (for
I'm very sure that it would still happen and even be "needed" for
that refuse any sane way of building or packaging. Like not using
(The "apple way" of inserting a GNUmakefile for those could be
But when the overrides are outnumbering the defaults, then something
> What is becoming increasingly obvious (to me if not to you) is that
> the lack
> of a grammar for spec files, and the abuse of macros, is
> interfering with the
> reliability of building OSS software.
Yes, this interfering is rather evident when "porting" a specfile
openSUSE (or Mandriva) over to something say like Fedora (or CentOS)
Both the macros, and the tomatoo/tomaato naming of package
I guess the names could be handled by some kind of "standard"
> Sure you can accomplish just about any goal you wish by treating
> existing spec
> files as a template, and overloading existing tokens to insert
> additional goop
> into a build.
> But why bother using spec files for this purpose? If you want a
> paramaterized template
> for builds, then why not design a format that is more reliable than
> spec files are?
> There are certainly better templating candidates around than rpm
> spec files and macros,
> autoconf (and m4) and make(1) and ant instantly come to mind.
I usually try to use/patch the Makefile to build and install the
with all the dirty details, and the Specfile to mostly do the
I'm not sure that switching one legacy language (spec) for another
would help much other than to confuse it even further. But that's
> I'm increasingly convinced (see my FOSDEM 2005 presentation
> abstract) that's its time to eliminate rpmbuild in
> favor of more reliable and flexible means to produce *.rpm packages.
But it could still use the command "rpmbuild --rebuild *.src.rpm",
I guess we're more talking about what goes inside the source package...
Maybe something like http://bee.rubyforge.org/ would keep more within
the existing YAML-ish syntax, while still allowing for a Real Language ?
Received on Sun Sep 7 22:27:44 2008