forked from devzero2000/RPM5
-
Notifications
You must be signed in to change notification settings - Fork 0
/
INSTALL
462 lines (359 loc) · 18.4 KB
/
INSTALL
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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
REQUIREMENTS
============
Development-Time
----------------
--------------- --------- --------------- -------------------------------------
Component Component Version Version Component
Name Type Minimum Used URL
--------------- --------- ------- ------- -------------------------------------
CVS mandatory 1.12 1.12.13 http://www.nongnu.org/cvs/
Perl mandatory 5.8.0 5.10.1 http://www.perl.com/
GNU m4 [0] mandatory 1.4.0 1.4.13 http://www.gnu.org/software/m4/
GNU autoconf mandatory 2.59b 2.63 http://www.gnu.org/software/autoconf/
GNU automake mandatory 1.8 1.11.1 http://www.gnu.org/software/automake/
GNU libtool mandatory 1.5 2.2.6a http://www.gnu.org/software/libtool/
GNU gettext mandatory 0.16 0.17 http://www.gnu.org/software/gettext/
GNU make mandatory - - http://www.gnu.org/software/make/
GNU bash optional - - http://www.gnu.org/software/bash/
--------------- --------- ------- ------- -------------------------------------
Build-Time
----------
--------------- --------- --------------- -------------------------------------
Component Component Version Version Component
Name Type Minimum Used URL
--------------- --------- ------- ------- -------------------------------------
ISO C Compiler mandatory - - e.g. http://gcc.gnu.org/
POSIX make mandatory - - e.g. http://www.gnu.org/software/make/
Perl mandatory 5.8.0 5.10.1 http://www.perl.com/
POPT mandatory 1.15 1.16 http://rpm5.org/files/popt/
BeeCrypt mandatory 4.2.0 4.2.1 http://beecrypt.sourceforge.net/
Libtasn.1 mandatory - 2.7 http://www.gnu.org/software/libtasn1/
Neon mandatory 0.27.0 0.29.4 http://www.webdav.org/neon/
PCRE mandatory 7.0 8.10 http://www.pcre.org/
Mozilla NSS optional 3.11 3.12.8 http://www.mozilla.org/projects/security/pki/nss/
OpenSSL optional 0.9.8 1.0.0a http://www.openssl.org/
Berkeley-DB [1] optional 5.1.19 5.1.19 http://www.oracle.com/database/berkeley-db.html
SQLite [1] optional 3.3 3.7.0.1 http://www.sqlite.org/
Lua [2] optional 5.1 5.1.4 http://www.lua.org/
ZLib optional 1.2 1.2.3 http://www.zlib.net/
Bzip2 optional 1.0 1.0.5 http://www.bzip.org/
XZ Utils [3] optional 4.999.9 4.999.9 http://tukaani.org/xz/
File/magic [4] optional 4.00 5.03 ftp://ftp.astron.com/pub/file/
GNU gettext optional 0.18 0.18 http://www.gnu.org/software/gettext/
GNU iconv optional 1.11 1.11 http://www.gnu.org/software/libiconv/
OSSP uuid optional 1.6.0 1.6.2 http://www.ossp.org/pkg/lib/uuid/
XAR [5] optional 1.5.2 1.5.2 http://code.google.com/p/xar/
DMalloc optional 5 5.5.2 http://dmalloc.com/
Electric Fence optional 2.1 2.1.13 http://perens.com/FreeSoftware/ElectricFence/
Linux KeyUtils optional 1.2 1.2 http://people.redhat.com/~dhowells/keyutils/
System libelf optional - - e.g. http://www.mr511.de/software/english.html
CPUInfo optional r143 r143 https://launchpad.net/cpuinfo
--------------- --------- ------- ------- -------------------------------------
[0] m4: NOTICE: Do not use GNU m4 1.4.10, it breaks GNU autoconf.
[1] db/sqlite: Berkeley-DB used by RPM.
Building RPM against anything _EXCEPT_ db-5.1.19
external Berkeley-DB is not officially supported
(but any version of Berkeley-DB since db-4.5.20 will "work").
[2] lua: Modified Lua copy bundled with RPM.
Building RPM against stock external Lua not recommended
as it reduces its RPM-specific functionality.
[3] xz: XZ Utils copy is bundled with RPM because there is no
"official" XZ release and too many variants in the wild.
[4] file: File/magic copy can bundled with RPM to control for magic
strings used in *.rpm tag content.
Building RPM against stock external File/magic supported, too.
NOTICE: File 4.24 is unportable because uses asprintf(3)
without fallbacks.
[5] xar: Modified XAR copy bundled with RPM.
Building RPM against stock external XAR currently still not recommended.
The 1.5 and 1.5.1 releases of XAR needs some patching, before they work.
Run-Time
--------
--------------- --------- --------------- -------------------------------------
Component Component Version Version Component
Name Type Minimum Used URL
--------------- --------- ------- ------- -------------------------------------
GNU zip optional - - http://www.gzip.org/
Bzip2 optional - - http://www.bzip.org/
XZ optional 4.999.9 4.999.9 http://tukaani.org/xz/
GNU tar optional - - http://www.gnu.org/software/tar/
GNU cpio optional - - http://www.gnu.org/software/cpio/
UnZip optional - - http://www.info-zip.org/UnZip.html
GnuPG optional - - http://www.gnupg.org/
--------------- --------- ------- ------- -------------------------------------
PROCEDURE
=========
Development-Time
----------------
$ ./devtool jbj|standalone
Build-Time
----------
$ ./configure --prefix=<prefix> [...]
$ make
$ make install [DESTDIR=...]
Run-Time
--------
$ <prefix>/bin/rpm --initdb
$ <prefix>/bin/rpm --rebuild foo.src.rpm
$ <prefix>/bin/rpm -Uvh /path/to/binary/package/foo.*.rpm
$ <prefix>/bin/rpm -qa
$ <prefix>/bin/rpm -e foo
Application Build-Time
----------------------
CPPFLAGS = `pkg-config rpm --cflags-only-I`
CFLAGS = `pkg-config rpm --cflags-only-other`
LDFLAGS = `pkg-config rpm --libs-only-other`
LIBS = `pkg-config rpm --libs-only-l`
BUILDING RPM ON A CLUSTER OF SERVERS
====================================
Assume you have...
- a cluster of time-synchronized Unix servers
(usually of different Unix flavors to make sense in this context),
- each server allowing you to login under your personal account and
access your central home directory (usually via NFS) and
- each server providing you the full set of development tools,
...then you can build RPM in parallel on an arbitrary number of servers
in this cluster by using the following procedure:
1. Build Environment Preparation:
On a single arbitrary server of the cluster prepare the RPM source
tree at least once.
server1$ cd ~/work
server1$ cvs -d rpm-cvs@rpm5.org:/v/rpm/cvs co rpm
server1$ cd rpm
server1$ . devtool.bashrc
server1$ devtool checkout
server1$ devtool autogen
2. Platform Preparation:
on every(!) server of the cluster prepare its platform-specific
environment (includes building local copies of all third-party
libraries).
serverN$ cd ~/work/rpm
serverN$ . devtool.bashrc
serverN$ devtool setup-platform
serverN$ devtool standalone prepare
serverN$ devtool standalone configure
3. Development:
now you can develop RPM on any number of servers of the cluster in
parallel.
serverN$ cd ~/work/rpm
serverN$ . devtool.bashrc
serverN$ cd {build,lib,rpmdb,rpmio,misc,...}
serverN$ vi *.c
serverN$ devtool make
4. Test-Drive:
on an arbitrary server of the cluster you can test-drive RPM via:
serverN$ cd ~/work/rpm
serverN$ . devtool.bashrc
serverN$ devtool make install
serverN$ /tmp/rpm/bin/rpm [...]
LIBRARY ISSUES
==============
RPM is a rather comphrehensive tool with both internal dependencies and
optional external dependencies. The current internal structure is (in
partly dependency order from top to bottom):
RPM Executables: rpm
(stage 0) rpmbuild
RPM Libraries: librpmconstant
(stage 1) librpmbuild
librpm
librpmdb
librpmio
librpmmisc
Third-Party Libraries: libpopt (mandatory)
(stage 2) libbeecrypt (mandatory)
libdb (mandatory)
libpcre (mandatory)
libsqlite3 (optional)
liblua (optional)
libz (optional)
libbz2 (optional)
liblzma (optional)
libintl (optional)
libiconv (optional)
libxar (optional)
libdmalloc (optional)
libefence (optional)
libkeyutils (optional)
libelf (optional)
libneon (optional)
Third-Party Libraries: libxml2 (required by libxar)
(stage 3) libz (required by libxar)
libexpat (required by libneon)
libssl (required by libneon)
libcrypto (required by libssl)
System Libraries: libc (required by all)
(stage 4) libm (required by some)
[...]
The most important aspects to notice are: librpmbuild requires mainly
librpm, librpm in turn requires both librpmdb and librpmio, and all
librpm* require librpmmisc. Additionally; librpmmisc is a container for
the internal local copies of third-party libraries, and librpmconstant
provides RPM API constants (usually to language bindings). Finally,
notice that the set of third-party libraries at stage 2 can be dynamically
chosen at build-time and are not a fixed set.
Unfortunately, there are many link-time approaches to handle these
internal and external dependencies. The currently implemented approach
is a portable compromise balancing the following particular issues:
- Dynamic/Static Libraries:
librpmXXX can be built and installed statically (librpmXXX.a) or
dynamically (librpmXXX.so). This is handled by GNU libtool and
controlled by Autoconf options --{enable,disable}-{shared,static}.
- Installed/Uninstalled Libraries:
libfoo can be in an installed (after "make install") or uninstalled
(just after "make") state. Both are supported by GNU libtool but in
totally different ways. GNU libtool especially treats the linking of a
library against an uninstalled one specially by _copying_ all objects
of the dependency library into the to be be built library.
- Regular/Convenience Libraries:
GNU libtool knows a special "convenience" library. These are
uninstalled libfoo.la's which are linked into another (still
uninstalled) libbar.la.
- Library Type Combinations:
GNU libtool knows how to handle all situations caused by _combinding_
the different types of libraries: installed/uninstalled,
static/dynamic and regular/convinience. And in RPM nearly _ALL_ of
those combinations actually occur under various Autoconf options.
Although the processing abstracted, the resulting libraries have
different characteristics and affects how RPM-based applications are
able to link about the RPM libraries.
- External Dependencies:
librpmXXX and librpmYYY usually depend on the _same_ third-party
library libfoo. Although GNU libtool handles this seamlessly, one can
easily end up with multiple copies of a code in the same RPM-based
application.
- Non-Fixed Third-Party Libraries:
RPM supports to be built against a non-fixed set of third-party
libraries, ranging from _none_ at all to half a dozen ones.
Especially, the cases of "none" and "some" have to taken into account.
- Transitive Dependencies:
libfoo usually has dependencies to other third-party libraries and
those dependencies can be even just optional. For instance libneon
can optionally depend on OpenSSL's libssl and libcrypto and the W3C
libxml.
- Internal Modified Local Copies:
because of optional but RPM-specific modifications, some third-party
libraries are even provided as internal copies in the RPM source
tree. Those libraries have to be handled specially as they are built
together with RPM. This means that for instance one cannot test-link
against them during configure-time.
- Dependency Encoding:
there are multiple ways an inter-library dependency can be encoded:
directly in an ELF librpmXXX.so as DT_NEEDED (not available
everywhere), indirectly via "dependency_libs" in librpmXXX.la, via
"Libs:" in rpm.pc, or either via a _FULL INCLUDED COPY_ of all objects
or not at all in case of librpmXXX.a, etc.
Before complaining that the currently implemented library approach
of RPM is not "standard", doesn't "just work" as expected for your
particular situation, etc please first make sure you understood that
it is balanced compromise in order to portably take care of all of
the above issues at once. So, if you want to change the current
implementation please at least make sure that the above issues are still
taken care of and especially test it under _different_ Unix flavors.
DEBUGGING
=========
Memory Allocation Debugging with DMalloc
----------------------------------------
1. Install DMalloc into /path/to/dmalloc
2. Build RPM with at least:
$ ./configure [...]
--prefix=/tmp/rpm \
--with-dmalloc=/path/to/dmalloc
[...]
$ make
$ make install
3. Enable dmalloc debugging with:
$ . .dmalloc.bashrc
$ dmalloc -l dmalloc.log
$ dmalloc debug3
4. Run RPM:
$ /tmp/rpm/bin/rpm [...]
5. Inspect the results:
(notice that some used functions like gethostbyname(3) or dirname(3)
from the vendor libc inherently leak memory because of their API
style and because libc isn't DMalloc instrumented you will often see
some memory leaks reported without any source location -- just be not
confused)
$ vi dmalloc.log
OS DEPENDENCIES
===============
Under Red Hat Linux all libraries (in fact all files distributed with
the OS) are under RPM control and this section is not an issue.
RPM will need to be informed of all the dependencies which were
satisfied before RPM was installed. Typically this only refers to
libraries that are installed by the OS, but may include other
libraries and packages which are availible at the time RPM is
installed and will not under RPM control. Another common example of
libraries which may need dependency provisions are precompiled
libraries which are installed by the OS package manager during system
build time. The list of dependencies you will wish to load into RPM
will depend on exactly how you bootstrap RPM onto your system and what
parts of the sytem you put into packages as well as on the specific OS
you are using.
The script vpkg-provides.sh can be used to generate a package which
will satisfy the dependencies on your system. To run it you will need
to create a specfile header for this empty package and run the progam
with:
--spec_header '/path/to/os-base-header.spec
and if you wish to ensure that some directories are not traversed you
can use the option:
--ignore_dirs 'egrep|pattern|of|paths|to|ignore
By default the generated rpm will include a %verifyscript to verify
checksum of all files traversed has not changed. This additional
check can be surpressed with:
--noverify
The result of running the script will be a specfile which will create
a package continging all the dependencies found on the system. There
will be one provides line for each depednecy. The package will contain
none of the actual OS library files as it is assumed they are already
on your system and managed by other means. Here is a example
(truncated) of the provides lines used by one user of Digital Unix. (I
have put several provides on the same line for brevity)
provides: /bin/sh /usr/bin/ksh /usr/bin/csh
provides: libc.so.osf.1 libm.so.osf.1 libcurses.so.xpg4 libdb.so.osf.1
provides: libX11.so libXaw.so.6.0 libXext.so libXm.so.motif1.2 libXmu.so
provides: libdnet_stub.so.osf.1 libsecurity.so.osf.1 libpthread.so.osf.1
provides: libexc.so.osf.1 libmach.so.osf.1 libdps.so libdpstk.so
rpmfilename:
-----------
If you plan on packaging for more then one OS you may want to edit
/etc/rpm/macros or /usr/lib/rpm/macros and change the line which has
rpmfilename to something which includes both the %{_target_os} and
%{_target_cpu}. This will cause the name of the generated rpm files
to the operating system name as well as the architecture which the rpm
runs under. The line to change looks like:
%_rpmfilename %%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
you may wish to include both the %{_target_os} and %{_target_cpu} in
the final base name, so that it's easier to distinguish between what
package is appropriate for a particular arch-os-version combo. We
suggest:
%_rpmfilename %%{_target_platform/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{_target_platform}.rpm
There is no %{_target_os_version} tag, so if you need to also
distinguish between RPMs for certain versions of the OS, you can
hard-code the version in the macros on the build machine, so that
.rpm files are generated with the version as part of the filename.
For example when one user builds RPMs for Digital Unix 4.0b and 4.0d,
optimization is important and he will build one set of RPMs for the
EV4 processor and another set for the EV56 processor. He specifies
both the OS version (if it's important, as it is for a few packages)
and the processor version by default by setting a special rpmfilename:
on the particular build machine.
The "rpmfilename: "tag on one machine (Digital Unix 4.0d, EV56 PWS 433)
looks like:
rpmfilename: %{_target_os}/4.0d/%{_target_cpu}/%{name}-%{version}-%{release}.%{_target_os}-%{_target_cpu}ev56.rpm
For package `foo-1.1', at build time that would translate into:
osf1/4.0d/alpha/foo-1.1-1.osf1-alphaev56.rpm
The hyphen between the %{_target_cpu} and ev56 is left out for compatibility
with GNU Config.guess and because `alphaev56' looks more "normal" to
people with an alpha than alpha-ev56 for someone on an Intel Pentium
Pro would want `i586pro' over `i586-pro', but it does make parsing
this filename by other programs a bit more difficult.
GPG
------------
To use the signing features of rpm, you will need to configure certain
rpm macros.
Here's what I use for gpg:
/etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
%_signature gpg
%_gpg_name Jeff Johnson (ARS N3NPQ) <jbj@redhat.com>
%_gpg_path /home/jbj/.gnupg
(Note: Both pgp/pgp5 can be used with RPM just noone has tried in >8 years.)