Jeff Johnson wrote:
Increasingly I'm seeing spec file recipes (and rpmbuild) used in
horrendously
complicated ways.
rpm spec file recipes contain "known good" (at least wrto rpmbuild
parsing/execution)
content that results in successful builds and binary packages to be
distributed.
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)
in MacPorts...
And if the recipes were using say XML (for metadata) and Python (for
scripting),
I'm very sure that it would still happen and even be "needed" for
those packages
that refuse any sane way of building or packaging. Like not using
autofoo/gnumake.
(The "apple way" of inserting a GNUmakefile for those could be
explored, though.)
But when the overrides are outnumbering the defaults, then something
is wrong...
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
from say
openSUSE (or Mandriva) over to something say like Fedora (or CentOS)
or so.
Both the macros, and the tomatoo/tomaato naming of package
dependencies...
I guess the names could be handled by some kind of "standard"
dictionary.
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
software,
with all the dirty details, and the Specfile to mostly do the
metadata...
I'm not sure that switching one legacy language (spec) for another
(make),
would help much other than to confuse it even further. But that's
just me.
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",
right ?
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 ?
--anders
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
