Building RPMs
ROM is similar to self-installable archive popular in DOS world and
availble in all major archivers, such a RAR. It is more strcutured Every RPM package has a package label, which contains the following
pieces of information:
- the software name
- the software version (the version taken from original "upstream"
source of the software)
- the package release (the number of times the package has been
rebuilt using the same version of the software). This field is also
often used for indicating the specific distribution for example "fc4" (Fedora
Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE
Linux 10.0) etc.
- the architecture the package was built for (i386, i686, athlon,
ppc, etc.). RPM files with the noarch.rpm
extension refer to files which do not depend on a certain computer's architecture.
These files usually include graphics and text for another program to use,
and sometimes programs written in an interpreted programming language, such
as
Python programs and
shell scripts.
RPM file names normally have the following format:
<name>-<version>-<release>.<architecture>.rpm
For example:
nano-0.98-2.i386.rpm
A package label is contained within the file and does not necessarily
need to match the name of the file. Source code may also be distributed
in RPM packages. Such package labels do not have an architecture part and
replace it with "src", e.g.:
libgnomeuimm-2.0-2.0.0-3.src.rpm
Additionally, libraries are distributed in two separate packages for
each version. One contains the precompiled code, while the second one contains
the development files such as headers, static library files, etc. for the
library in question. Those packages have "-devel" appended to their name
field.
RPM packages are created
from RPM spec files using the rpmbuild
tool. When building an RPM pachge you need to create the directory with the
name of the package and several predefined subdirectories
-
SOURCES Contains the original sources, patches, and
icon files.
- SPECS
Contains the spec files used to control the build process.
- BUILD
The directory in which the sources are unpacked, and the
software is built.
- RPMS
Contains the binary package files created by the build
process.
- SRPMS
Contains the source package files created by the build
process.
The key component of the RPM package is SPECS section which contains
so called spec files which are very
similar to makefile. It contains information required by RPM to build
the package, as well as instructions telling RPM how
to build it. The spec files also specify what files are a part of the package,
and where they should be installed. They have the ".spec" suffix and are distributed within
source packages (SRPM)
It has multiple sections. Among them:
There are also several optional section
- Install and Uninstall Scripts. This is an optional
section. While the previous sections contained
either information required by RPM to build the package, or the actual
commands to do the deed, this section is different. It consists of scripts
that will be run, on the user's system, when
the package is actually installed or removed. RPM can execute a script:
- Prior to the package being installed.
- After the package has been installed.
- Prior to the package being erased.
- After the package has been erased.
One example of when this capability would be required is when a package
contains shared libraries. In this case, ldconfig
would need to be run after the package is installed or erased. As another
example, if a package contains a shell, the file
/etc/shells would need to be updated appropriately
when the package was installed or erased.
- The Verify Script. This is another script that is executed on the
user's system. It is executed when RPM verifies the package's proper
installation. While RPM does most of the work verifying packages, this
script can be used to verify aspects of the package that are beyond RPM's capabilities.
- The Clean Section. This is an optional section. Another script that can be present is a script
that can clean things up after the build. This script is rarely used,
since RPM normally does a good job of clean-up in most build environments.
The RPM package is a binary format and consists of four sections:[1]
- The lead identifies the file as an RPM file and contains some obsolete
headers.
- The signature which can be used to ensure integrity and/or authenticity
- The header contains
metadata
including package name, version, architecture, file list, etc..
- A file archive, which usually is
cpio compressed
with gzip.
In more recent versions of RPM, star can also be used for archive
and bzip2,
lzma or xz
for compression. RPM 5.0 format supports using
xar for archiving.
Working behind the scenes of the package manager is the RPM database,
stored in /var/lib/rpm. It uses
Berkeley
DB as its back-end. It consists of a single database (Packages)
containing all of the meta information of the installed rpms. Multiple databases
are created for indexing purposes, replicating data to speed up queries.
The database is used to keep track of all files that are changed and created
when a user (using RPM) installs a package, thus enabling the user (via
RPM) to reverse the changes and remove the package later. If the database
gets corrupted, the index databases can be recreated with the rpm
--rebuilddb command.
To build RPMs your system should have the rpmbuild command.
(If the command "which rpmbuild" does not display anything,
you don't have rpmbuild.). On Red Hat and Fedora systems, the
rpmbuild command is provided by the rpm-build
package. (You can give the command "rpm -q rpm-build" to check
if it is installed.) .
It is better to use some close example (prototype RPM), especially in
the source form then to build your RPM from scratch.
In this case you need first to install "prototype" RPM to your home directory.
To placing the package files under
$HOME/MyRPM and the rpm database in the
$HOME/MyRPM/var/rpm directory
use the command:
rpm -ivh --nodeps --relocate /=$HOME/MyRPM
--root=/$HOME/MyRPM package.rpm
To study RPM you can also
unpack
it Here is how to unpack an RPM without installing it.
# rpm2cpio emacs-common-21.4-20.el5.x86_64.rpm | cpio -idv
RPMs can be a great way to manage the packages you install on your
system. Unfortunately, not everything you might want to install is available
in RPM form. Perhaps you need a more recent version of a program than
the one that ships with your distribution; or maybe it's a program you
wrote yourself; or perhaps it's just something that's very obscure.
Similar dilemmas can occur with non-program packages, such as font or
clip art collections.
Whatever the case, if you're installing
a program for a single computer, chances are you'll just install it
the old-fashioned way, by typing
make && make install
(or some similar set of commands) in the source directory. make
gets the job done, but it means you're giving up the benefits of the
RPM system. What's more, if you're maintaining several computers, running
around installing the same package on all of them can be tedious.
Life would be much easier if you could create your own RPM, giving
you the ability to easily install the package on many systems and the
benefits of its package tracking. Fortunately, RPM includes tools that
enable you to do just that. Creating an RPM isn't as easy as creating
a tarball, but the task isn't insurmountable.
This month's column covers the files and file formats involved in
creating RPMs. Next month's column will present practical examples,
including how to build both binary and architecture-independent RPMs.
Never build RPMS as root.
- Log into your machine as a regular user.
- create a mirror image of the main RPM directory structure in your
$HOME and
- tell RPM to use these directories instead of the original ones.
Building RPM packages as userThis document explains how to build
packages without root-access. This might be useful in case you have
a build environment where different users need to build packages without
interfering each other.
Customizing your RPM build environment
To make RPM use your environment definitions, you need to override
the default macros RPM uses. The only one that is crucial for this
is %_topdir (which by default would point to /usr/src/redhat).
You can do this by adding the following to ~/.rpmmacros.
%_topdir /home/dag/redhat/
As a consequence, RPM will need the default directory structure
underneath. So you can do as user:
mkdir -p ~/redhat/{BUILD,RPMS/{i386,i686,noarch},SOURCES,SPECS,SRPMS}
And now you're set to go.
The obvious catch
Beware that you don't have the same permissions as root, which means
you can't chown files to other users. So if the default Makefile
uses chown or install to change ownership, this will obviously fail.
As a workaround, you can't use %makeinstall, and instead
use install yourself without changing owners. Ownerships should
be in the %files section.
Customize even more !
Since you now can build packages yourself, you can also customize
the default packager, vendor and other information by defining more
macros.
%packager Dag Wieers <[email protected]>
%vendor Dag Wieers <[email protected]>
%_tmppath /home/dag/tmp/
%_topdir /home/dag/redhat/
%prefix /usr/local/
There are much more macros for changing default paths, programs
or even function-macros. See our links for more specific information.
Recommended Links
rpm - Trac
- Maximum RPM A book
written by Ed Bailey. It is available in hardback (442
pages), and has recently been re-printed by Sams in
soft-cover (450 pages - ISBN: 0672311054). The hardcover
edition includes a quick reference card. An
on-line version of the
original book is also available, and a more up to date,
work in progress version can be found
here.
- Red Hat RPM Guide
A more recent book by Eric Foster-Johnson, this has
recently been released under the Open Publication License
and a draft close to the published version is available
on-line as
Fedora RPM Guide. This
book covers everything from basic usage to advanced
tricks, package creation and API programming. Participation
in updating the Guide can be done via the
Fedora Documentation Project.
Discussions about moving this content and work upstream
to rpm.org can occur on
fedora-docs-list.
AAA Development-Tasks-Packaging-Tools-RPM-Howto
- Mandriva Community Wiki a very good tutorial
Red Hat Package Manager 4
information
RPM Tutorial
[freshrpms.net] - The fight
Packaging software with RPM by Martin Streicher,
RPM HOWTO (Red Hat 1999)
Better Living Through RPM, Part 2
Society
Groupthink :
Two Party System
as Polyarchy :
Corruption of Regulators :
Bureaucracies :
Understanding Micromanagers
and Control Freaks : Toxic Managers :
Harvard Mafia :
Diplomatic Communication
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
Neoliberalism
: The Iron
Law of Oligarchy :
Libertarian Philosophy
Quotes
War and Peace
: Skeptical
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
Keynes :
George Carlin :
Skeptics :
Propaganda : SE
quotes : Language Design and Programming Quotes :
Random IT-related quotes :
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce :
Bernard Shaw :
Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
Vol 23, No.10
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan
(Win32/Crilock.A) :
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Copyleft Problems
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 :
Malware Protection Bulletin, 2010 : Vol 26,
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification
of sysadmin horror stories : Vol 25, No.05
(May, 2013) Corporate bullshit as a communication method :
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000):
the triumph of the US computer engineering :
Donald Knuth : TAoCP
and its Influence of Computer Science : Richard Stallman
: Linus Torvalds :
Larry Wall :
John K. Ousterhout :
CTSS : Multix OS Unix
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS
: Programming Languages History :
PL/1 : Simula 67 :
C :
History of GCC development :
Scripting Languages :
Perl history :
OS History : Mail :
DNS : SSH
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen :
OSS early history
Classic books:
The Peter
Principle : Parkinson
Law : 1984 :
The Mythical Man-Month :
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Haters Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk :
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
Ten Commandments
of the IT Slackers Society : Computer Humor Collection
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations
: Financial Humor :
Financial Humor Bulletin,
2008 : Financial
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor
: OFM Humor :
Politically Incorrect Humor :
IDS Humor :
"Linux Sucks" Humor : Russian
Musical Humor : Best Russian Programmer
Humor : Microsoft plans to buy Catholic Church
: Richard Stallman Related Humor :
Admin Humor : Perl-related
Humor : Linus Torvalds Related
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin,
2011 : Financial
Humor Bulletin, 2012 :
Financial Humor Bulletin,
2013 : Java Humor : Software
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM
Humor : Assembler-related Humor :
VIM Humor : Computer
Viruses Humor : Bright tomorrow is rescheduled
to a day after tomorrow : Classic Computer
Humor
The Last but not Least Technology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Last modified:
September 13, 2011
