head	1.5;
access;
symbols
	rpm-4_4_8-release:1.5
	rpm-4_4_7-release:1.5
	rpm-4_4_6-release:1.5
	rpm-4_4_5-release:1.5
	rpm-4_4_4-release:1.5
	rpm-4_4_3-release:1.5
	jbj_before_tklcpatches:1.5
	rpm-4_4_2-release:1.5
	pjones-sparse-experiment:1.5.0.6
	rpm-4_4_1-release:1.5
	rpm-4_4-release:1.5
	rpm-4_4:1.5.0.4
	rpm-4_3_1-start:1.5
	rpm-4_3:1.5.0.2
	rpm-4_2_1-release:1.4
	rpm-4_1_1-release:1.4
	rpm-4_2-release:1.4
	rpm-4_2:1.4.0.4
	rpm-4_1-release:1.4
	rpm-4_1:1.4.0.2
	rpm-4_0_4-release:1.2.10.2
	jbj-before-beecrypt:1.2.10.2
	rpm-4_0_3-release:1.2.10.2
	jbj_b4_rollback:1.2.10.2
	rpm-4_0_2-release:1.2
	rpm-4_0_1-release:1.2
	rpm-3_0_6-release:1.2
	rpm-4_0-release:1.2
	rpm-3_0_6:1.2
	rpm-4_0:1.2.0.10
	rpm-3_0_5:1.2.0.8
	jbj_sparc64:1.2.0.6
	rpm-3_0_4:1.2.0.4
	rpm-3_0_3:1.2.0.2;
locks; strict;
comment	@# @;


1.5
date	2003.12.30.13.14.50;	author jbj;	state Exp;
branches;
next	1.4;

1.4
date	2001.03.17.19.55.09;	author jbj;	state Exp;
branches
	1.4.4.1;
next	1.3;

1.3
date	2001.03.14.23.09.09;	author jbj;	state Exp;
branches;
next	1.2;

1.2
date	99.09.07.16.24.20;	author jbj;	state Exp;
branches
	1.2.10.1;
next	1.1;

1.1
date	99.07.19.22.13.12;	author jbj;	state Exp;
branches;
next	;

1.2.10.1
date	2001.03.15.18.32.54;	author jbj;	state Exp;
branches;
next	1.2.10.2;

1.2.10.2
date	2001.04.21.05.43.35;	author jbj;	state Exp;
branches;
next	;

1.4.4.1
date	2003.12.30.13.17.46;	author jbj;	state Exp;
branches;
next	;


desc
@@


1.5
log
@- spelling corrections (#112728).
@
text
@/*! \page buildroot Using a build root

The build root is very similar to Root: (which is now legacy).
By using Buildroot: in your spec file you are indicating
that your package can be built (installed into and packaged from)
a user-definable directory.  This helps package building by normal
users.

\subsection buildroot_specfile The Spec File

Simply use
\verbatim
  Buildroot: <dir>
\endverbatim

in your spec file.  The actual buildroot used by RPM during the
build will be available to you (and your %prep, %build, and %install
sections) as the environment variable RPM_BUILD_ROOT.  You must
make sure that the files for the package are installed into the
proper buildroot.  As with Root:, the files listed in the %files
section should *not* contain the buildroot.  For example, the
following hypothetical spec file:

\verbatim
  Name: foo
  ...
  Root: /tmp
  
  %prep
  ...
  
  %build
  ...
  
  %install
  install -m755 fooprog /tmp/usr/bin/fooprog
  
  %files
  /usr/bin/fooprog
\endverbatim

would be changed to:

\verbatim
  Name: foo
  ...
  BuildRoot: /tmp
  
  %prep
  ...
  
  %build
  ...
  
  %install
  install -m755 fooprog $RPM_BUILD_ROOT/usr/bin/fooprog
  
  %files
  /usr/bin/fooprog
\endverbatim

\subsection buildroot_building Building With a Build Root

RPM will use the buildroot listed in the spec file as the default
buildroot.  There are two ways to override this.  First, you can
have "buildroot: <dir>" in your rpmrc.  Second, you can override
the default, and any entry in an rpmrc by using "--buildroot <dir>"
on the RPM command line.

\subsection buildroot_caveats Caveats using Build Roots

Care should be taken when using buildroots that the install directory
is owned by the correct package.  For example the file

\verbatim
	/usr/lib/perl5/site_perl/MD5.pm
\endverbatim

is installed by the package perl-MD5.  If we were to use a buildroot
and specified 

\verbatim
	%files  
	/usr/lib/perl5/site_perl
\endverbatim

we would end up with the directory /usr/lib/perl5/site_perl being
owned by the library package. This directory is in fact used by ALL
perl libraries and should be owned by the package for perl not any of
its libraries. It is important that the %files command specifies all
the known directories explicitly. So this would be preferable:

\verbatim
	/usr/lib/perl5/site_perl/*
\endverbatim

Since we only want the files and directories that the package perl-MD5
installed into /usr/lib/perl5/site_perl/ to be owned by the package.
The directory /usr/lib/perl5/site_perl/ is created when perl is
installed.

If we were to use the bad %files line shown above, then when the MD5
package is removed, RPM will try to remove each of the perl-MD5 files and
then try to remove the dir itself. If there's still files in the
site_perl directory (e.g. from other packages) then the Unix rmdir(2)
will fail and you will get a non-zero return code from RPM. If the
rmdir succeeds then you will no longer have a site_perl directory on
your machine even though this directory was created when Perl was
installed.

The other common problem is that two packages could install two files
with the the same name into the same directory. This would lead to
other collision problems when removing the file. Care should be taken
by the packager to ensure that all packages install unique files.
Explicit use of %files can help make the packager aware of potential
problems before they happen. When you try to install a package which
contains file names already used by other packages on the system then
RPM will warn you of the problem and give a fatal error. This error can
be overridden with --force and the installed file will be replaced by the
new file and when the new package is removed the file will be removed as well.

*/
@


1.4
log
@Doco updates.
@
text
@d16 1
a16 1
in your spec file.  The acutal buildroot used by RPM during the
d89 1
a89 1
perl libriares and should be owned by the package for perl not any of
d107 1
a107 1
rmdir succeds then you will no longer have a site_perl directory on
d119 1
a119 1
be overriden with --force and the installed file will be replaced by the
@


1.4.4.1
log
@- spelling corrections (#112728).
@
text
@d16 1
a16 1
in your spec file.  The actual buildroot used by RPM during the
d89 1
a89 1
perl libraries and should be owned by the package for perl not any of
d107 1
a107 1
rmdir succeeds then you will no longer have a site_perl directory on
d119 1
a119 1
be overridden with --force and the installed file will be replaced by the
@


1.3
log
@Update to doxygen-1.2.6 configuration.
Add manual files to Doxfile.in.
lclint annotations.
@
text
@d9 1
a9 1
<h2>The Spec File</h2>
d62 1
a62 1
<h2>Building With a Build Root</h2>
d70 1
a70 1
<h2>Caveats using Build Roots</h2>
@


1.2
log
@suggested changes to docs from Ken Estes (#4451).
@
text
@d1 1
a1 2
BUILD ROOT
==========
d3 2
a4 2
The build root is very similar to Root: (which will be deprecated
soon).  By using Buildroot: in your spec file you are indicating
d9 1
a9 2
The Spec File
-------------
d12 1
a12 1

d14 1
d24 1
d40 1
d44 1
d47 1
a47 1
  Buildroot: /tmp
d60 1
d62 1
a62 2
Building With a Build Root
--------------------------
d70 1
a70 2
Caveats using Build Roots
-------------------------
d75 1
d77 1
d82 1
d85 1
d93 1
d95 1
d121 2
@


1.2.10.1
log
@- update per-interpreter dependency scripts, add sql/tcl (#20295).
- fix: rpmvercmp("1.a", "1.") returned -1, not +1 (#21392).
@
text
@d1 2
a2 1
/*! \page buildroot Using a build root
d4 2
a5 2
The build root is very similar to Root: (which is now legacy).
By using Buildroot: in your spec file you are indicating
d10 2
a11 1
<h2>The Spec File</h2>
d14 1
a14 1
\verbatim
a15 1
\endverbatim
a24 1
\verbatim
a39 1
\endverbatim
a42 1
\verbatim
d45 1
a45 1
  BuildRoot: /tmp
a57 1
\endverbatim
d59 2
a60 1
<h2>Building With a Build Root</h2>
d68 2
a69 1
<h2>Caveats using Build Roots</h2>
a73 1
\verbatim
a74 1
\endverbatim
a78 1
\verbatim
a80 1
\endverbatim
a87 1
\verbatim
a88 1
\endverbatim
a113 2

*/
@


1.2.10.2
log
@Flush tos onto rpm-4_0 branch.
@
text
@d9 1
a9 1
\subsection buildroot_specfile The Spec File
d62 1
a62 1
\subsection buildroot_building Building With a Build Root
d70 1
a70 1
\subsection buildroot_caveats Caveats using Build Roots
@


1.1
log
@add pl translation and man pages (Tomasz K?oczko et al).
@
text
@d67 47
@

