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.
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.
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.
Here is a rather simple popt alias for a --queryformat that starts to
convert a specfile
into Makefile rules.
Put this in /etc/popt:
==============================================================
rpm alias --spec:makefile --qf '\
# Display spec file scriptlets as Makefile targets \
\n# (indentation of sections not yet implemented) \
\n\
\nall: %{NAME}.prep %{NAME}.build %{NAME}.install %{NAME}.clean\
\n\
\n.PHONY: %{NAME}.prep\
\n%{NAME}.prep:\
\n%{Buildprep}\
\n\
\n.PHONY: %{NAME}.build\
\n%{NAME}.build:\
\n%{Buildbuild}\
\n\
\n.PHONY: %{NAME}.install\
\n%{NAME}.install:\
\n%{Buildinstall}\
\n\
\n.PHONY: %{NAME}.clean\
\n%{NAME}.clean:\
\n%{Buildclean}\
\n' \
--POPTdesc=$"display spec file scriptlets as Makefile rules"
==============================================================
(aside) Yes, I haven't attempted Makefile indentation nor filtering
the tag content, not impossibly hard.
Then create a Makefile from any *.spec by doing
rpm -q --spec:makefile --specsrpm foo.spec
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.
Other opinions?
73 de Jeff
Received on Sun Sep 7 19:19:42 2008