Bug 114338

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 
         /usr/include/db4/db.h

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
or BuildHints.  

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:
 /usr/share/packaging/%{name}/BuildHint-%{name}[[-%{Epoch}:]-%{Version}[-%{Release}]]

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
file.

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:

He said:
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

--
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:
     Requires: perl(bar::baz) 
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:
    Requires(hint):
    Suggests:
    Enhances:

Dunno BuildSuggests et al. Hang on lemme check ...

All of
    BuildRequires(hint):
    BuildSuggests:
    BuildEnhances:
are now recognized by the spec file parser.

Changes are in rpm cvs, will be in rpm-4.4.3-0.32 when built.