January 7th, 2004

cAos policy on buildreqs and hints for rpm packages
===================================================

In a cAos RPM spec file, "BuildReq" statements are considered 
"authoritative". 

"Hint" statements (located in a separate file or database) 
serve two purposes for cAos RPM packages. Primarily, when a 
package may be advantagous to have in the build environment, 
but is not a requirement, a package "Hint" may be added at a 
package builder's discretion. Secondly, package "Hint"s may be 
added as a supplement to package "BuildReq"s when the 
maintainer cannot or has not yet added "BuildReq" statements 
to the spec file. 

"Hint"s should only be used when absolutely necessary. 


Consider: https://bugzilla.caosity.org/show_bug.cgi?id=71


<orc_caos> the bug 71 example about 'hinting' to the gimp build that PNG would
+be nice is a really nice illustration of why autotools require hints rather
+than requrements; RH has made a decision sometimes to REQUIRE the xf86-libs
+to be present at build time, which makes all systems fatter; if it were just
+a hint, a given builder gets to make that decision.  

<orc_caos> also, there is the jbj lament that RPM is just a packaging system,
+and not a build system -- keeping hints OUT of a .spec file (they actually
+could be inside the .spec file as a custom tag) re-affirms RPM's role as a
+Package MANAGER, and not a Package Builder;  Tools like Mezzanine, designed to
+be builders can do a better job of building.

see: http://www.kainx.org/mezzanine/

<orc_caos> troj: a buildmaster's modification are captured in the package
+listing which my buildscript emits in each case, so that others examining it
+can see the full build environment;

See: http://www.owlriver.com/projects/packaging/fedora-flow.txt
at section S-3b referencing
	%{name}-%{epoch}-%{version}-%{release}-environment.txt,
and its manner of creation at section S-5

hints' come in, then called "Additional packages" as mentioned in section S-2

<orc_caos> it turns out that is not enough -- building anaconda parts, for
+example, also look at build environment %defines and env-vars;  under the
+GPL, sec 4, and by rights, if asked, one should be able to convince RH to 
+disclose this information;  I am considering how get the build ENV and 
+command line into the buildlogs, but no clear method comes to mind, 
+except a 'set  >> ' and an 'echo' of the line calling rpmbuild

 
<KainX> We'll try it one way, and if it doesn't work, we'll fix it.
<gmkurtzer> KainX: ok. we shall.
<KainX> It just would've been nice to know about the BuildRequires 
+thing a week or so ago so that I could've added it to Mezzanine already. :)
<gmkurtzer> KainX: I agree... I didn't realize there was a issue 
+with the current implementation.
<gmkurtzer> that may be my fault for not seeing the bugzilla's on them
<KainX> gmkurtzer: My understanding (albeit flawed) from our discussions 
+in the past was that hints were exhaustive and authoritative. I just 
+need to go back and add that support in.
<gmkurtzer> Hrmm, I was under the impression that hints were supposed 
+to be used lightly...
<KainX> Bugs 71 and 72 are of particular interest.  If BuildReq's are 
"authoritative" and hints are merely a supplement for when we can't or 
+haven't yet added BuildReq's, that's fine.
<gmkurtzer> lol, we need to talk more.
<KainX> Apparently so. :)

<gmkurtzer> I think that bug 71 is a perfect example of a hint
* KainX goes to flesh out his parse_spec_file() routine a bit more.
<gmkurtzer> the package builds with the buildrequies satisified
<gmkurtzer> but adding a hint allows a feature to be detected in autoconf
<gmkurtzer> maybe I am reading it wrong, but it sounds like we are in 
+agreement...
<KainX> For CentOS that makes sense, but for cAos it would seem prudent 
+to update the spec file.
<gmkurtzer> Agreed.

[later aside by orc:  I am not so sure; KainX and I share a strong distaste
for 'cluttering'  a .spec file with too many manual BuildRequires -- every 
added item in a .spec file adds to maintenance decisions; it also reduces
the chances that a given SRPM will build cleanly on a later or earlier
release within a distribution line (package renaming. etc.), and even more 
outside of its original packaging.  The Mandrake, and more the PLD, and even 
more, the Alt RPM based distributions use vendor local macros and %defines
within their .spec files for build system management reasons fine for them,
bad for builders.]

<gmkurtzer> are you ok if we continue to maintain hints as long as they are 
+used in a fashion of a staging area for buildreqs?
<gmkurtzer> so we will utilize hints and buildreqs, but they must be used 
+right?
<KainX> From a practical standpoint, I won't care, because Mezzanine will 
+need to support both anyway.  But from an administrative standpoint, I'd 
+prefer that hints only be used when absolutely necessary, like when we 
+can't/won't edit a package.
<gmkurtzer> KainX: agreed.
<gmkurtzer> so now we just need to have someone document it. lol


----------------
Revised and extended 040109 RPH
----------------
Revised 040109 TAJ