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

Re: [rpm] Re: Making RPMs from Anywhere (more like Irix 'gendist')

More thoughts about %_specdir ...

On Tue, 14 Nov 2000, James Ralston wrote:

> You can override these.  The default values are defined in
> /usr/lib/rpm/macros (or the equivalent location to wherever you've
> installed rpm), and are:
>     %_usr                   /usr
>     %_usrsrc                %{_usr}/src
>     %_topdir                %{_usrsrc}/redhat
>     %_specdir               %{_topdir}/SPECS

> Well, you don't really need %_specdir, as I don't believe anything in
> rpm automatically looks for spec files there.  (When you pass a spec
> file as an argument to "rpm -ba" and the like, you're passing a
> *path*, not a simple filename; rpm won't automatically look for that
> spec file in %_specdir.)

... ummm --- Not strictly needed for first builds, but needed for
the verification of the 'pristine sources' concept, and to ensure
that something needful was not omitted.  Maybe it (rpm) _could_
automatically look in %_specdir, but it is safer practice to specify
exact path.

This macro entry ("%_specdir") exists in large part, in the build
process meta-function, to provide a well known (but local option
over-rideable) directory, in which rpm may place JUST the specfile
encountered in _unpacking_ a .src.rpm -- As such, a seperate QA
person can diff each of the content files in ~/SPECS and ~/SOURCE,
and know that nothing needed to build was omitted from the .src.rpm

[Recall that pristine sources, patches, and specfile are ALL that a
well-packaged .src.rpm file needs to ensure Build Dependency
satisfaction, and to rebuild itself, if possible for a given

That is, once a full rpm -ba cycle has been performed, an identical
set of ~/SPECS, and ~/SOURCE files should be produceable from a
given .src.rpm ... and should be able to produce functionally
identical binaries in the ~/RPMS tree, and internal file content in
~/SRPMS (build timestamps, and signatures will vary in the latter

Good practice indicates that after one _thinks_ one has a good
package, the next steps to _prove_ its goodness include: 

(1) being able to locally rebuild cleanly from the specfile left in
~/SPECS/ for a given package, and then

(2) with just the .src.rpm on another host, foreign rebuild cleanly.

This is a better way to ensure that there was not some wierd file in
the build environment of the original local buildhost, which would
prevent a third-party rebuild. (... which I have hit twice in the
last week with some packages which I have been building, from less 
careful sites.)

-- Russ

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