[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Reproducible builds; was: Re: RPM's that fail in %post...

<warning: longish think piece, and a couple of questions>

On Wed, 15 Jan 2003, Jeff Johnson wrote:

> FWIW, there are 2 big lies in rpm:
> 	1) reproducible builds.
> #1 is true iff one knows how to set up a build environment.

This one is interesting to me -- the iff -- 'one knows how to
set up a build environment' -- is not a well documented
matter, and outside of the scope of day-to-day RPM usage.

The discussion between Jim Knoble and Jeff Johnson last week
got me thinking too.  The perspective of Jim and his
clientele, and Jeff at Red Hat, but also Jeff building the
future RPM, and Jeff supporting the community of RPM users on
non-RHL distributions, represent at least four competing
constituencies.  I am certain there are more views.

And so the topic of how 'one knows' the _right_ "build
environment" is not outside the scope of RPM generally.  

trpm is a tool, esentially without comments or usage notes,
which JBJ has remarked on a couple of times on the list that
he uses for build testing.  I've worked through trying to
divine the whole picture, and am not satisfied with my

IANAHNBARHE.  More broadly, in reviewing Changelogs and
specfiles, it appears that Red Hat corporate uses an internal
role account, probably automated, probably also 'fed' with
guidance and suggests for rebuild requests, called
'prospector' to perform routine updateing and first draft
builds.  Other tools like the perl packager approaches in the
CPAN port back at RHL 7.1, and later exist as well.  The
Red Hat builder farm system manager seems to be called 


"* Wed Jul 17 2002 Elliot Lee <sopwith@redhat.com> 4.05-2
  - Add fortune-mod to buildprereq to make beehive happy
  - Fix find_lang usage - install translations properly by 
specifying datadir"

"* Thu Jul 13 2000 Prospector <bugzilla@redhat.com>
  - automatic rebuild"

It is not uncommon in the industry to perform periodic,
continuous incremental, or nightly 'make world' rebuilds --
the Mozilla project has documented and implemented this
nicely.  The _Deathmarch_ book documented this at MicroSoft as

Periodically, new SRPM and RPM versions appear at Raw Hide --
if one maintains a mirror of Raw Hide, as I have since it
started in 1998, and study the daily updated packages, one can
infer parts of the near future. Less often, new Red Hat point 
releases, or even new major releases appear.


Clearly, a packager and a builder gets different results,
depending on whether certain -devel libraries are present --
autoconf will find or notice absence of a given library
header, and if present build one way or another.

Manually specified 'Buildrequires' can "force" the presence of 
a given -devel package (unless one chooses to amend the 
.specfile).  Options passed to autoconf within a .specfile can 
vary this further.  

I have filed RFE's to make express BuildRequirements into the
RH Bugzilla from time to time, and sometimes they are
accepted, other times not.  The policy seems to vary by
package maintainer at Red Hat.

.... and so the questions I have are:

1.  What 'know how' and practice do Red Hat, and others 
follow as to setting up a 'repeatable' build environment?

My answer is:

I build from SRPM, on both an automated 'make world' type
basis, and also manually, by and large, on a group of hosts
which I try to leave as a 'basic install with all updates'
host, at the end of each Red Hat Major Release.  Somw of that 
fruit end up at: ftp://ftp.owlriver.com/pub/local/ORC/

But I do NOT go back after solveing Build Requirements either
manually or with my autobuilder, and REMOVE added packages or
versions -- so over time, my build environment contains later
packages than a fresh install with all updates.

This caused some pain to 'autorpm' at version 2, which Kirk 
Bauer's understanding of readline variations and mine in RHL 
7.x varied.  It caused RPMs built on my build hosts to not 
install on RHL 7.0 and 7.1 hosts, without the target hosts 
applying some updates first.

In a perfect world, one would have a networked kickstart 
installer build an absolute fresh host for every compile, 
apply all the updates to current, and then attempt a build, 
and solve (on an automated basis, of course) the build 
requirements, adding just the minimum packages required to 
satisfy the .spec file mandates, and the rpmbuild process 
minimum path.

I'd like to do that, but ... not today.  I'm working on it.

What do other list members do?

and second question, which is more to JBJ:

2)  Is there a cheatsheat or set of common forms used with 
trpm which we might see?

-- Russ Herrold

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []