Traditionally, rpm was designed primarily as a package manager, and
only secondarily (and more recently grown more) as a aid to building.
The .spec file has a number of tags, which have grown over time, and
have been extended. I propose the addition of a new 'BuildHint:' tag
A most useful tag, to determine if a build environment is complete
enough to yield a functional result, is the 'Buildrequire' tag. there
is presently discussion about extending that tag, to add an inline
(rather than a %if surrounded) 'Arch', and possibly 'Color' modifier.
This tag can be over-ridded with the --nodeps argument to rpmbuild.
There have also grown up several backage building systems, to build
within a well-populated chroot. 'mach', the Conectiva approach, the
cAos approach, and the KainX Mezzanine, each have mechanisms to pass
in packages which are not strictly mandatory to be present, but when
present will produce a more useful result after an rpmbuild.
As an example, Gimp will build without the -lpng autoconf check being
satisfied -- the auto-tools do not, and cannot know what elements of
the build environment are mandatory, and which are merely optional in
a given instance. (this would require knowint the external packager's
desires; clearly outside rpmbuild's scope); as another example, the
old, gif-supporting GD and the newer png using variants might each be
wanted and will satisfy a build of PHP -- but with open source and
patent license issues, only the later versioned PNG supporting variant
To permit a packager to express the desired, as well as the presently
require build environment, I propose addition of a .specfile tag,
which will be treated as a %nil by rpmbuild, of the name:
It will accept RHS content of the same type as BuildRequire: ,
splitting on the ':'
It is processable by simple text manipulation and parseing tools --
(awk, perl, etc)
It states a 'soft' BuildRequire, and requires no affirmative act from
rombuild, save to ignore the line as a %nil action.
It has no particular adverse legacy effects which I can see.
This is not speculative; the ORCbuildit and Mezzanine need this
feature for carrying, within the SRPM bundle, this kind of build
Thanks -- Russ Herrold
an interesting 'heresy' crossed #rpm today:
12:02 jbj> PlasmaHH: i live with that annoyance every day, so can
you. the guarantee that rpm provides that a pkg can be rebuilt
reproducibly from a src.rpm on some build system is important to OSS
even if annoying.
In order to get closer to a reproducible rebuild goalstate, we need to
be able to control the buildsystem contenst, and to 'capture' build
environment SETs and command line options used. The GPL, v. 2, para
3, also states:
> For an executable work, complete source code means all the source
> code for all modules it contains, plus any associated interface
> definition files, plus the scripts used to control compilation and
> installation of the executable.
Arguably, with the addition of the BuildHints tags, we will _assist_
all packagers in meeting their requirement of providing part of 'any
associated interface definition files' information (the libraries
anticipated to be found and therefore the conditional compilation
paths and options [as by the auto-tools, or by conditional macro
expanstion and evaluation paths by rpmbuild]).
I leave for another day, filing an RFE to enumerate the present
BuildEnv: and BuildArg: within the .spec file, for better GPL compliance.
First item: A suggestion from KainX today on #caos points out that
'Hint' is perhaps less descriptive of what is going on than a
Debian-ish 'Suggest' -- If a BuildHint is added to the syntax of a
.spec file, it may be more proper to call it a 'BuildSuggest'
Alternative approach; My limited purpose in requesting this, is for
'ex post' usage (that is, initially a manually maintained repository
point [inside the .spec file, in a tag array], enumerating packages
(or files, thinking here of the nice package independent example of
/usr/include/db.h as a clear marker that db[234(whatever)]-devel is
present inthe build environment
bash-2.05b$ ls -l `rpm -ql db4-devel | grep db.h `
lrwxrwxrwx 1 root root 8 Feb 8 18:44
/usr/include/db.h -> db4/db.h
-r--r--r-- 1 root root 67730 Dec 30 14:45
parenthetical ends). I am presently largely uninterested in
automatedly generating 'Hints'; I am also not much excited at relying
on a .spec file loaded with automatically generated 'BuildRequires'
In reviewing some traffic on the mach development list in the last
week, and elsehwere, I certainly understand (but disagree with) the
allure of automatically (prior to or immediately after a test pass
build) emitting .spec files fully populated with lots of BuildRequires
I see this a lot in bringing in Alt Linux content. In their wv2 .spec
file of recent vintage, there is a part:
# Automatically added by buildreq on Tue Jan 20 2004 (-bi)
BuildRequires: gcc-c++ glib2-devel glibc-devel
BuildRequires: libgsf-devel libstdc++-devel libxml2-devel pkgconfig
and I think this misses the point of a BuildRequire, and certainly the
purpose of a BuildHint -- It is NOT to enumerate everything which is
needed to compile a package -- clearly 'glibc-devel' is so basic that
no reasonable build environment would lack it.
A proper purpose is to give _enough_ information to an already
'reasonably' stocked build chroot, to permit automated tools to bring
in 'the rest' of what is needed (rather like we do not carry '/bin/sh'
around as a Requires: for every package).
Sensible factoring out of common items is needed, or we will tie our
future in to a bloated fat environment (full of phantom
'Dependencies'). This approach may be friendly for one buildsystem,
but such false (and versioned, no less!!) Buildrequires are already
making recent Fedora content much less usable by the people who have
to feed them, and solve build stickpoints. [One Fedora QA 'standard'
mandates much more enumeration of BuildRequires than in the past, and
it is affecting useability and interoperability with other Third-Party
archives and Distributions]
Final thought for the evening:
It may be sufficient for my purposes to simply adopt the packaging
convention of adding a %file stanza element of:
and then have as SourceN that file. Opening the SRPM would permit my
autobuilder access to pull out what it needs (being in a well named
form), without the RPM backversion support pain of altering the .spec
Credit where due: I was travelling and am catching up on email; I see
that KainX made the suggestion on Suggests earlier on rpm-devel list:
I was thinking perhaps BuildSuggests: would be better, since it fits
with the plurality of Conflicts, Obsoletes, Provides, and Requires
better than Hint(s).
Michael Jennings (a.k.a. KainX)
I lied: new last thought for the evening:
Later kainX said:
> Bring me consensus on syntax and semantics, and I will be happy to
> implement BuildSuggests:.
I'll work on it once orc returns from Mexico.
Counterpoint on 'BuildSuggests' is that we may confuse some Deianista
who wanders into a .spec file, as the scope of Suggests is for the
Package manager (apt, in this case); and not buildrecipe builder
instructions (And this is an extension of the general lament that RPM
is just a package manager, not designed to me a buildtool adjunct)
I have no pride of nameing Hints; either is fine by me.
No formal BNF grammar (more's the pity), but:
A LHS: RHS syntax delimited by a tagname on the Left, and the value
stream on the right is so pervasive in RPM that we cannot reasonably
abandon it (exceptions SourceN and PatchN; otherwise, we use either
hyphen options on stanza options (%description -n value), or comma
delimited RHS arrays (Requires: foo, bar, baz)).
Then there are the nasty generated Requires like:
and one assumes we might even eventually want:
Requires: perl >= 5.6.0, perl(bar::baz) >= 3.03
I have a strong preference to use a marker like () or even better a 
pair, and _not_ context nor whitespace, to set off the arch aspects
for the parser, not that this is something I anticipate using soon.
I think the concept of "BuildSuggests" would make a "Debianista" feel
right at home. It's the same basic concept: not strictly required,
but probably a good thing to have.
I also believe that the Suggests: concept might be beneficial in
certain circumstances, but it would only make sense to a dep engine
like yum or apt that points to an inclusive repository. Suggests: for
packages installed on the command line makes little sense.
Hints are now possible with any of the following (equivalent) syntaxes:
Dunno BuildSuggests et al. Hang on lemme check ...
are now recognized by the spec file parser.
Changes are in rpm cvs, will be in rpm-4.4.3-0.32 when built.