summaryrefslogtreecommitdiff
path: root/doc/manual/buildroot
blob: 7c9facd65434dc556eb65d60655849ed9efdf5de (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
BUILD ROOT
==========

The build root is very similar to Root: (which will be deprecated
soon).  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.

The Spec File
-------------

Simply use

  Buildroot: <dir>

in your spec file.  The acutal 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:

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

would be changed to:

  Name: foo
  ...
  Buildroot: /tmp
  
  %prep
  ...
  
  %build
  ...
  
  %install
  install -m755 fooprog $RPM_BUILD_ROOT/usr/bin/fooprog
  
  %files
  /usr/bin/fooprog

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.

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

	/usr/lib/perl5/site_perl/MD5.pm

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

	%files  
	/usr/lib/perl5/site_perl

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 libriares 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:

	/usr/lib/perl5/site_perl/*

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 succeds 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 overriden 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.