Initial revision
CVS patchset: 795 CVS date: 1996/07/12 02:31:16
This commit is contained in:
ewt
parent
3d2adecc22
commit
0d58d15991
|
|
@ -0,0 +1,110 @@
|
||||||
|
DEPENDENCIES
|
||||||
|
============
|
||||||
|
|
||||||
|
Dependencies provide a way for a package builder to require other
|
||||||
|
packages or capabilities to be installed before or simultaneously
|
||||||
|
with one another. These can be used to require a python interpretor
|
||||||
|
for a python based application for example. RPM ensures dependencies
|
||||||
|
are satisfied whenever packages are installed, erased, or upgraded.
|
||||||
|
|
||||||
|
Requiring Packages
|
||||||
|
------------------
|
||||||
|
|
||||||
|
To require packages, use:
|
||||||
|
|
||||||
|
Requires: python perl
|
||||||
|
|
||||||
|
in the spec file. Note that "Requires python, perl" would work as well. If you
|
||||||
|
needed to have a very recent version of python but any version of perl,
|
||||||
|
|
||||||
|
Requires: python >= 1.3, perl
|
||||||
|
|
||||||
|
would do the trick. Again, the ',' in the line is optional. Instead of
|
||||||
|
'>=', you may also use '<', '>', '<=', or '='.
|
||||||
|
|
||||||
|
RPM uses an internal algorithm to determine version number orderings which
|
||||||
|
works correctly most of the time. For example, it will know that
|
||||||
|
1.9a is older then 1.9b. However, it will also be later then 1.9 which
|
||||||
|
may or may not be correct as some programmers use letters in version numbers
|
||||||
|
to indicate beta versions.
|
||||||
|
|
||||||
|
To work around this, you may specify a serial number for a package like this:
|
||||||
|
|
||||||
|
Serial: 23
|
||||||
|
|
||||||
|
If a Requires: line should be comparing the given number with a serial number
|
||||||
|
instead of a version number, you would do this:
|
||||||
|
|
||||||
|
Requires: somepackage =S 23
|
||||||
|
|
||||||
|
Virtual Packages
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Sometimes you need to make sure the system your package is being installed
|
||||||
|
on has a package which provides a certain capability, even though you don't
|
||||||
|
care what specific package provides it. For example, sendmail won't work
|
||||||
|
properly unless a local delivery agent (lda) is present. You can ensure that
|
||||||
|
one is installed like this:
|
||||||
|
|
||||||
|
Requires: lda
|
||||||
|
|
||||||
|
This will match either a package called lda (as mentioned above), or any
|
||||||
|
package which contains:
|
||||||
|
|
||||||
|
Provides: lda
|
||||||
|
|
||||||
|
in its .spec file. No version numbers may be used with virtual packages.
|
||||||
|
|
||||||
|
Automatic Dependencies
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
To reduct the amount of work required by the package builder, RPM scans
|
||||||
|
the file list of a package when it is being built. Any files in the file
|
||||||
|
list which require shared libraries to work (as determined by ldd) cause
|
||||||
|
that package to require the shared library.
|
||||||
|
|
||||||
|
For example, if your package contains /bin/vi, RPM will add dependencies
|
||||||
|
for both libtermcap.so.2 and libc.so.5. These are treated as virtual
|
||||||
|
packages, so no version numbers are used.
|
||||||
|
|
||||||
|
A similar process allows RPM to add Provides information automatically. Any
|
||||||
|
shared library in the file list is examined for its soname (the part of
|
||||||
|
the name which must match for two shared libraries to be considered
|
||||||
|
equivalent) and that soname is automatically provided by the package. For
|
||||||
|
example, the libc-5.3.12 package has provides information added for
|
||||||
|
libm.so.5 and libc.so.5. We expect this automatic dependency generation
|
||||||
|
to eliminate the need for most packages to use explicit Requires: lines.
|
||||||
|
|
||||||
|
Installing and Erasing Packages with Dependencies
|
||||||
|
-------------------------------------------------
|
||||||
|
|
||||||
|
For the most part, dependencies should be transparent to the user. However,
|
||||||
|
a few things will change.
|
||||||
|
|
||||||
|
First, when packages are added or upgraded, all of their dependencies
|
||||||
|
must be satisfied. If they are not, an error message like this appears:
|
||||||
|
|
||||||
|
failed dependencies:
|
||||||
|
libICE.so.6 is needed by somepackage-2.11-1
|
||||||
|
libSM.so.6 is needed by somepackage-2.11-1
|
||||||
|
libc.so.5 is needed by somepackage-2.11-1
|
||||||
|
|
||||||
|
Similarly, when packages are removed, a check is made to ensure that
|
||||||
|
no installed packages will have their dependency conditions break due to
|
||||||
|
the packages being removed. If you wish to turn off dependency checking for
|
||||||
|
a particular command, use the --nodeps flag.
|
||||||
|
|
||||||
|
Querying with Dependencies
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
Two new query information selection options are now available. The first,
|
||||||
|
--provides, prints a list of all of the capabilities a package provides.
|
||||||
|
The second, --requires, shows the other packages that a package requires
|
||||||
|
to be installed, along with any version number checking.
|
||||||
|
|
||||||
|
There are also two new ways to search for packages. Running a query with
|
||||||
|
--whatrequires <item> queries all of the packages that require <item>.
|
||||||
|
Similarly, running --whatprovides <item> queries all of the packages that
|
||||||
|
provide the <item> virtual package. Note that querying for package that
|
||||||
|
provides "python" will not return anything, as python is a package, not
|
||||||
|
a virtual package.
|
||||||
|
|
@ -0,0 +1,93 @@
|
||||||
|
QUERY FORMATS
|
||||||
|
=============
|
||||||
|
|
||||||
|
As it is impossible to please everyone with one style of query output, RPM
|
||||||
|
allows you to specify what information should be printed during a query
|
||||||
|
operation and how it should be formatted.
|
||||||
|
|
||||||
|
Tags
|
||||||
|
----
|
||||||
|
|
||||||
|
All of the information a package contains, apart from signatures and the
|
||||||
|
actual files, is in a part of the package called the header. Each piece
|
||||||
|
of information in the header has a tag associated with it which allows
|
||||||
|
RPM to to tell the difference between the name and description of a
|
||||||
|
package.
|
||||||
|
|
||||||
|
To get a list of all of the tags your version of RPM knows about, run the
|
||||||
|
command 'rpm --querytags'. It will print out a list like (but much longer
|
||||||
|
then) this:
|
||||||
|
|
||||||
|
RPMTAG_NAME
|
||||||
|
RPMTAG_VERSION
|
||||||
|
RPMTAG_RELEASE
|
||||||
|
RPMTAG_SERIAL
|
||||||
|
RPMTAG_SUMMARY
|
||||||
|
RPMTAG_DESCRIPTION
|
||||||
|
RPMTAG_BUILDTIME
|
||||||
|
RPMTAG_BUILDHOST
|
||||||
|
RPMTAG_INSTALLTIME
|
||||||
|
RPMTAG_SIZE
|
||||||
|
|
||||||
|
As all of these tags begin with RPMTAG_, you may omit it from query format
|
||||||
|
specifiers and it will be omitted from the rest of this documentation for
|
||||||
|
the same reason.
|
||||||
|
|
||||||
|
A tag can consist of one element or an array of elements. Each element can
|
||||||
|
be a string or number only.
|
||||||
|
|
||||||
|
Query Formats
|
||||||
|
-------------
|
||||||
|
|
||||||
|
A query format is passed to RPM after the --queryformat argument, and normally
|
||||||
|
should be enclosed in single quotes. This query format is then used to print
|
||||||
|
the information section of a query. This means that when both -i and
|
||||||
|
--queryformat are used in a command, the -i is essentially ignored.
|
||||||
|
|
||||||
|
The query format is similar to a C style printf string, which the printf(2)
|
||||||
|
man page provides a good introduction to. However, as RPM already knows the
|
||||||
|
type of data that is being printed, you must omit the type specifier. In
|
||||||
|
its place put the tag name you with to print enclosed in curly braces
|
||||||
|
({}). For example, the following RPM command prints the names and sizes
|
||||||
|
of all of the packages installed on a system:
|
||||||
|
|
||||||
|
rpm -qa --queryformat "%{NAME} %{SIZE}\n"
|
||||||
|
|
||||||
|
If you want to use printf formatters, they go between the % and {. To
|
||||||
|
change the above command to print the NAME in the first 30 bytes and
|
||||||
|
right align the size to, use:
|
||||||
|
|
||||||
|
rpm -qa --queryformat "%-30{NAME} %10{SIZE}\n"
|
||||||
|
|
||||||
|
Arrays
|
||||||
|
------
|
||||||
|
|
||||||
|
RPM uses many parallel arrays internally. For example, file sizes and
|
||||||
|
file names are kept as an array of numbers and an array of strings
|
||||||
|
respectively, with the first element in the size array corresponding
|
||||||
|
to the first element in the name array.
|
||||||
|
|
||||||
|
To iterate over a set of parallel arrays, enclose the format to be used
|
||||||
|
to print each item in the array within square brackets ([]). For example,
|
||||||
|
to print all of the files and their sizes in the slang-devel package
|
||||||
|
followed by their sizes, with one file per line, use this command:
|
||||||
|
|
||||||
|
rpm -q --queryformat "[%-50{FILENAMES} %10{FILESIZES}\n]" slang-devel
|
||||||
|
|
||||||
|
Note that since the trailing newline is inside of the square brackets, one
|
||||||
|
newline is printed for each filename.
|
||||||
|
|
||||||
|
Formatting Tags
|
||||||
|
---------------
|
||||||
|
|
||||||
|
One of the weaknesses with query formats is that it doesn't recognize
|
||||||
|
that the INSTALLTIME tag (for example) should be printed as a date instead
|
||||||
|
of as a number. To compensate, you can specify one of a few different
|
||||||
|
formats to use when printing tags by placing a colon followed the formatting
|
||||||
|
name after the tag name. Here are some examples:
|
||||||
|
|
||||||
|
rpm -q --queryformat "%{NAME} %{INSTALLTIME:date}\n" fileutils
|
||||||
|
rpm -q --queryformat "[%{FILEMODES:perms} %{FILENAMES}\n]" rpm
|
||||||
|
rpm -q --queryformat \
|
||||||
|
"[%{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n]" \
|
||||||
|
vlock
|
||||||
|
|
@ -0,0 +1,36 @@
|
||||||
|
RELOCATABLE PACKAGES
|
||||||
|
====================
|
||||||
|
|
||||||
|
Relocatable packages are a way to give the user a little control
|
||||||
|
over the installation location of a package. For example, a vendor
|
||||||
|
may distribute their software to install in "/opt" but you'd like
|
||||||
|
it to install in "/usr/opt". If the vendor were distributing a
|
||||||
|
relocatable RPM package, it would be easy.
|
||||||
|
|
||||||
|
Building a Relocatable Package
|
||||||
|
------------------------------
|
||||||
|
|
||||||
|
Not all software can be "relocatable". Before continuing you should
|
||||||
|
think about how the program works, what files it accesses, what other
|
||||||
|
programs access *it* (and expect it to be in a certain place), etc.
|
||||||
|
If you determine that the location of the package doesn't matter,
|
||||||
|
then it can probably be built as "relocatable".
|
||||||
|
|
||||||
|
All you need to do to build a relocatable package is put:
|
||||||
|
|
||||||
|
Prefix: <dir>
|
||||||
|
|
||||||
|
in your spec file. The "<dir>" will usually be something like "/usr",
|
||||||
|
"/usr/local", or "/opt". Every file in your %files list must start
|
||||||
|
with that prefix. For example, if you have "Prefix: /usr" and your
|
||||||
|
%files list contains "/etc/foo.conf", the build will fail.
|
||||||
|
|
||||||
|
Installing Relocatable Packages
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
By default, RPM will install a relocatable package in the prefix
|
||||||
|
directory listed in the spec file. You can override this on the
|
||||||
|
RPM install command line with "--prefix <dir>". For example, if
|
||||||
|
the package in question were going to be installed in "/opt" but
|
||||||
|
you don't have enough disk space there (and it is a relocatable
|
||||||
|
package), you could install it "--prefix /usr/opt".
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
New RPM Signatures
|
||||||
|
==================
|
||||||
|
|
||||||
|
The 2.1 release of RPM had a few improvements in the area of
|
||||||
|
digital package signatures. The usage of PGP has been cleaned
|
||||||
|
up and extended, the signature section in the RPM file format
|
||||||
|
has been made easily extensible with new signature types, and
|
||||||
|
packages can have multiple signatures.
|
||||||
|
|
||||||
|
PGP
|
||||||
|
---
|
||||||
|
|
||||||
|
RPM's previous usage of PGP was cumbersome, and only supported
|
||||||
|
1024 bit keys. Both of these problems have been corrected.
|
||||||
|
|
||||||
|
Whereas previously you needed many rpmrc entries to clue in
|
||||||
|
RPM about keyring locations and such, RPM now behaves as PGP
|
||||||
|
users would expect. The PGPPATH environment variable can be
|
||||||
|
used to specify keyring locations. You can also use a
|
||||||
|
"pgp_path:" line in your rpmrc to specify a different value
|
||||||
|
for RPM to use for PGPPATH. If neither of these are used PGP
|
||||||
|
uses its default ($HOME/.pgp).
|
||||||
|
|
||||||
|
If you just want to verify packages, you do not need any entries
|
||||||
|
in your rpmrc (except possibly "pgp_path:"). The minimal rpmrc
|
||||||
|
entries to use PGP for package building are:
|
||||||
|
|
||||||
|
signature: pgp
|
||||||
|
pgp_name: <name to uniquely select the key to use for signing>
|
||||||
|
|
||||||
|
Signature Creation
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Signature creation is the same as previous releases: just add
|
||||||
|
a --sign to your build command line. You can sign a package
|
||||||
|
after the package is built with:
|
||||||
|
|
||||||
|
rpm --resign <package>
|
||||||
|
|
||||||
|
Using --resign removes any previous signature in the package.
|
||||||
|
To *add* a signature to a package, leaving all existing
|
||||||
|
signatures use:
|
||||||
|
|
||||||
|
rpm --addsign <package>
|
||||||
|
|
||||||
|
RPM always creates MD5 and SIZE signatures when it build
|
||||||
|
packages, which means that packages built without --sign can
|
||||||
|
be "verified" to some extent. The MD5 signature should catch
|
||||||
|
problems like corrupt packages, faulty downloads, etc.
|
||||||
|
|
||||||
|
Signature Verification
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
Package signature verification is the same as previous releases:
|
||||||
|
|
||||||
|
rpm -K <package>
|
||||||
|
|
||||||
|
RPM will verify evey signature in the package, which may include
|
||||||
|
more than one PGP signature. The output indicates what types of
|
||||||
|
signatures are being checked. If any checks fail you'll see a
|
||||||
|
"NOT OK" message, and you should be worried.
|
||||||
|
|
||||||
|
If you have a package with PGP signatures, but don't have PGP
|
||||||
|
installed, but still want to verify it as much as possible, you
|
||||||
|
can do:
|
||||||
|
|
||||||
|
rpm -K --nopgp <package>
|
||||||
|
|
||||||
|
That will cause RPM to skip any PGP signatures, but still check
|
||||||
|
any others (currently only MD5 and SIZE).
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
SPEC FILE ADDITIONS
|
||||||
|
===================
|
||||||
|
|
||||||
|
A few additions have been made to the spec file format.
|
||||||
|
|
||||||
|
Summary and Description
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
The Summary: tag should be use to give a short (50 char or so) summary
|
||||||
|
of the package. Most package's Description: line should be changed to
|
||||||
|
a Summary: line. The Description: tag is still supported but should
|
||||||
|
be changed to a "%description" entry similar to %package and %files.
|
||||||
|
At some point in the future support will be removed for "Description:".
|
||||||
|
As an example, this spec file fragment:
|
||||||
|
|
||||||
|
Description: Screen drawing library
|
||||||
|
Name: screenlib
|
||||||
|
Version: 1.0
|
||||||
|
|
||||||
|
%package devel
|
||||||
|
Description: Screen drawing library headers and static libs
|
||||||
|
|
||||||
|
might be changed to:
|
||||||
|
|
||||||
|
Summary: Screen drawing library
|
||||||
|
Name: screenlib
|
||||||
|
Version: 1.0
|
||||||
|
|
||||||
|
%description
|
||||||
|
The screen drawing library
|
||||||
|
is a handy development tool
|
||||||
|
|
||||||
|
%package devel
|
||||||
|
Summary: Screen drawing library headers and static libs
|
||||||
|
|
||||||
|
%description devel
|
||||||
|
This package contains all of the
|
||||||
|
headers and the static libraries for
|
||||||
|
screenlib.
|
||||||
|
|
||||||
|
You'll only need this package if you
|
||||||
|
are doing development.
|
||||||
|
|
||||||
|
The description is free form text, but there are two things to note.
|
||||||
|
The first regards reformating. Lines that begin with white space
|
||||||
|
are considered "pre-formatted" and will be left alone. Adjacent
|
||||||
|
lines without leading whitespace are considered a single paragraph
|
||||||
|
and may be subject to formatting by glint or another RPM tool.
|
||||||
|
|
||||||
|
Other Tags
|
||||||
|
----------
|
||||||
|
|
||||||
|
Two new tags are "URL:" and "Packager:". "URL:" is a place to put a
|
||||||
|
URL for more information and/or documentation on the software
|
||||||
|
contained in the package. Some future RPM package tool may make use
|
||||||
|
of this. The Packager: tag is meant to contain the name and email
|
||||||
|
address of the person who "maintains" the RPM package (which may be
|
||||||
|
different from the person who actually maintains the program the
|
||||||
|
package contains).
|
||||||
Loading…
Reference in New Issue