Библиотека сайта rus-linux.net
Source Package Files and How To Use Them
etcskel-1.0-3. |
src. Is that a new kind of computer?
If you use RPM on an Intel-based computer, you'd normally expect to find
i386 there. Maybe someone messed up the name of
the file. Well, we know that the file command can
display information about a package file, even if the filename has been
changed. We've used it before to figure out what package a file
contains:
|
In this example, foo.bar is an RPM version 2 file,
containing an executable package — hence, the
"bin" — built for Intel processors —
the "i386". The package is eject version 1.2,
release 2.
|
Well, it's a package file all right — for version 1.0, release 3
of the etcskel package. It's in RPM version 2
format, and built for Intel-based systems. But what does the
"src" mean?
A gentle introduction to source code
This package file contains not the executable, or "binary", files that a normal package contains, but rather the "source" files required to create those binaries. When programmers create a new program, they write the instructions, often called "code", in one or more files. The source code is then compiled into a binary that can be executed by the computer.
As part of the process of building package files (a process we cover in great detail in the second half of this book), two types of package files are created:
The binary, or executable, package file
The source package file
The source package contains everything needed to recreate not only the programs and associated files that are contained in the binary package file, but the binary and source package files themselves.
Do you really need more information than this?
The following discussion is going to get rather technical. Unless you're the type of person who likes to take other people's code and modify it, chances are you won't need much more information than this. But if you're still interested, let's explore further.
So what can I do with it?
|
|
/usr/src/redhat/SOURCES. Let's take a look:
|
There are some files that seem to be related to
cdp there. The two files ending with
".patch" are patches to the source. RPM permits
patches to be processed when building binary packages. The patches
are bundled along with the original, unmodified sources in the source
package.
README files, a
Makefile or two, and some source code:
|
/usr/src/redhat/SPECS", so let's
see what we have in that directory:
|
Without making a long story too short, a spec file contains information used by RPM to create the binary and source packages. Using the spec file, RPM:
Unpacks the sources.
Applies patches (if any exist).
Builds the software.
Creates the binary package file.
Creates the source package file.
Cleans up after itself.
The neatest part of this is that RPM does this all automatically, under the control of the spec file. That's about all we're going to say about how RPM builds packages. For more information, please refer to the second half of this book.
Stick with us!
As we've noted several times, we'll be covering the entire subject of building packages with RPM, in the second half of the book. Be forewarned, however: Package building, while straightforward, is not a task for people new to programming. But if you've written a program or two, you'll probably find RPM's package building a piece of cake.
| Prev | Home | Next |
| Using rpm2cpio | Up | RPM and Developers — How to Distribute Your Software More Easily With RPM |