From herrold@owlriver.com Tue Feb 18 10:04:34 2003 Date: Thu, 16 Jan 2003 11:11:47 -0500 (EST) From: R P Herrold Reply-To: rpm-list@redhat.com To: RPM list Subject: rh-rpm] Reproducible builds; was: Re: RPM's that fail in %post... 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 answers. 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 'beehive'. See: http://rpmfind.net/linux/RPM/redhat/8.0/i386/xscreensaver-4.05-6.i386.html "* Wed Jul 17 2002 Elliot Lee 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 - 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 well. 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 _______________________________________________ Rpm-list mailing list Rpm-list@redhat.com https://listman.redhat.com/mailman/listinfo/rpm-list