User Tools

Site Tools


rpm

This is an old revision of the document!


RPM

Package management system few tips / trick to build / modify / work with packages.
Many hints information taken from original site RPM

How to Print .spec file from RPM

rpm --scripts -qp <rpmfile>

First RPM

Name of Package : libtorrent
Building it in folder “/usr/local/src/libtorrent”

mkdir /usr/local/src/libtorrent
cd /usr/local/src/libtorrent
mkdir BUILD RPMS SOURCES SPECS SRPMS

Creating macro not bad idea.

| /usr/local/src/libtorrent/.rpmmacros
%packager Ketan Patel

Get Sources from libtorrent
Place it in “/usr/local/src/libtorrent/SOURCES”
I have used following method.

cd /usr/local/src/libtorrent/SOURCES
svn co svn://rakshasa.no/libtorrent/trunk/libtorrent libtorrent
tar -cvf /usr/local/src/libtorrent/SOURCES/libtorrent.tar.gz libtorrent

Considering building rtorrent at non standard location.

NOTE : Please make sure code below has some SUSE Based Customization

| /usr/local/src/libtorrent/SPECS/libtorrent.spec
%define name libtorrent
%define srcdir /usr/local/src
%define _topdir %{srcdir}/libtorrent
 
 
summary: rTorrent
name: libtorrent
Source: libtorrent.tar.gz
License: GPL
version: 1
release: 1
Group: System/Utils
Prefix: /opt/libtorrent
buildarch: x86_64
BuildRoot: %{prefix}/%{name}-%{version}-%{release}-%{buildarch}-root
%define lib %{prefix}/lib64
%define include %{prefix}/include
Provides: libtorrent
Requires: ncurses, libcppunit-devel
AutoReqProv: no
 
 
%description
libtorrent is a BitTorrent client for ncurses, using
the libtorrent library. The client and library is
written in C++ with emphasis on speed and efficiency, while delivering
equivalent features to those found in GUI based clients in an ncurses
client.
 
%prep
%setup -q -n libtorrent
 
 
%build
chmod 755 autogen.sh
./autogen.sh
%{suse_update_config -f}
autoreconf -fiv
./configure --prefix=%{prefix} --libdir=%{lib}
make prefix=$RPM_BUILD_ROOT
 
%install
rm -rf %{buildroot}
make DESTDIR=$RPM_BUILD_ROOT install
rm -rf $RPM_BUILD_ROOT/%{prefix}/usr
 
 
%clean
make clean
rm -rf %{buildroot}
 
%files
%defattr(-,root,root,-)
%doc README
/opt/libtorrent/lib64/*
/opt/libtorrent/include/*
 
%post
echo "/opt/libtorrent/lib64/" > /etc/ld.so.conf.d/libtorrent.conf
ldconfig
 
%postun
rm -rf %{prefix}
rm /etc/ld.so.conf.d/libtorrent.conf
ldconfig
 
%Changelog
* Mon Nov 08 2010 Seriously, Check release son!!
Initial Build
Building Actual RPM
cd /usr/local/src/libtorrent
rpmbuild -v -bb --clean SPECS/libtorrent.spec

OR

rpmbuild -ba SPECS/libtorrent.spec
Test Your RPM
rpm -Vp RPMS/x86_64/libtorrent-1-1.x86_64.rpm

Sample RPM

| sample.spec
Name:      xgauguin-support
Summary:   xGauguin support metapackage
Version:   20110513
Release:   1.blip
Vendor:    lithiumfox
License:   none
Group:     Applications
URL:       http://lithiumfox.com
BuildRoot: %{_tmppath}/%{name}-%{version}-%(id -u -n)
BuildArch: noarch
Requires:  nginx, perl(Image::Size), perl(Params::Validate), perl(DateTime::Locale), perl(Class::Load), perl(parent), perl(DateTime::TimeZone), perl(Class::Singleton), perl(Test::Exception), perl(DateTime), perl(Image::Magick), perl(GD), perl(LWP), ImageMagick, gd, yum-utils
 
%description
Gauguin supporting packages
 
%install
[ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
%{__mkdir_p} %{buildroot}%{_localstatedir}/www/releases
%{__mkdir_p} %{buildroot}%{_localstatedir}/tmp/cache
 
%pretrans
## Force installation of conflicts
# libxml2.i386, perl-Locale-Codes
if $( ! rpm -q libxml2.i386 > /dev/null 2>&1)
  then
 
    yumdownloader libxml2.i386 > /dev/null 2>&1
    %{__rm} /var/lib/rpm/__db.000 > /dev/null 2>&1
    rpm --force -ivh libxml2*.rpm 
    %{__rm} libxml2*.rpm > /dev/null 2>&1
fi
 
if $( ! rpm -q perl-Locale-Codes > /dev/null 2>&1)
  then
    set -m
    yumdownloader perl-Locale-Codes > /dev/null 2>&1
    %{__rm} /var/lib/rpm/__db.000 > /dev/null 2>&1
    rpm --force -ivh perl-Locale-Codes*.rpm > /dev/null 2>&1
    %{__rm} libxml2*.rpm > /dev/null 2>&1
fi
 
%pre
## Check if vlad user exists, if not add them
if $( ! id vlad >/dev/null 2>&1) 
   then
     groupadd -g 1029 vlad > /dev/null 2>&1 ||: 
     useradd -u 1029 -g 1029 -d /home/vlad -s /bin/bash -p '$1asdf0' -m vlad > /dev/null 2>&1
fi
 
##Add user to sudoers
if $( ! grep vlad /etc/sudoers >/dev/null 2>&1)
  then
    echo "vlad ALL=NOPASSWD: /etc/init.d/nginx" >> /etc/sudoers
fi
 
%post
##Add nginx to startup
chkconfig --level 345 nginx on
 
##Create symlink for nginx.conf
if [ ! -h /etc/nginx/nginx.conf ]
  then
   ln -f -s %{_localstatedir}/www/prod/gauguin/current/conf/nginx-prod.conf %{_sysconfdir}/nginx/nginx.conf
fi 
 
 
%files
%defattr(-,root,root)
%attr(-,vlad,-) %{_localstatedir}/www/prod/xgauguin
%attr(777,-,-) %{_localstatedir}/tmp/xgauguin-cache
 
%changelog
* Fri May 13 2010 Jason Thomas <jason@lithiumfox.com> - %{version}
- Initial package creation

changelog

You can use following one liner for changelog.

awk '{print "*", $1, $2, $3, $6, "Jason Thomas <jason@lithiumfox.com>","-", "%{version}""\n""- initial rpm creation"}' <(date)

Good Reading

General RPM Command

List Content

rpm -qpl file.rpm

MOCK

Mock is a really nice tool to generate RPM cleanly.
I used KVM / MOCK to build RPM for my own reasons but you can use just mock and clean env. after every build.

General Details Available at Mock Project Page

Rather then guessing i have pasted all the command i have used to build RPM from srpm.
Using / Generating Spec require another tutorial this is strictly about some work around and keeping env. between transaction.

Install Mock
yum install mock
Add user to group

I am using rpmbuild user.

usermod -a -G mock rpmbuild
Initialize Mock

Before you work on anything Please initialize the environment.
It is good practice to initialize Environment between every build cycle to clean any possible left over or unforeseen issue.

mock --init -r epel-5-x86_64

su to user

You can not run mock as root so ….

su rpmbuild
Install required packages

I found that installed package stays installed during cycles.
So you do not require to install packages every time unless you initialize env.

/usr/bin/mock --install -r epel-5-x86_64 perl-libwww-perl.noarch

Copying Files

<note important>Dont scratch over –copyin check spelling one more time</note>

/usr/bin/mock -r epel-5-x86_64 --copyin pgpool-II-3.1.2.tar.gz /tmp/
Get SRPM
cd ~
wget http://ftp.arix.com/cpan2rpm-2.028-1.src.rpm
Finally Building RPM

<note> –no-clean : this will keep your files intact in build env.
–no-cleanup-after : i wanted to keep all work file so i used this just incase. </note>

/usr/bin/mock --rebuild --no-clean --no-cleanup-after -r epel-5-x86_64 cpan2rpm-2.028-1.src.rpm

In general case result will be stored in '/var/lib/mock/epel-5-x86_64/result/'

RPM Spec File Information

This is mostly from following URL Fedora Project

SPEC file overview
 
Other useful guides:
 
RPM Guide describes how to write a SPEC file.
The IBM series "Packaging software with RPM" Part 1, Part 2, and Part 3.
Maximum RPM has the most complete information, but is dated.
You will need to follow the Fedora guidelines: Package Naming Guidelines, Packaging guidelines, and Package review guidelines.
 
Insert comments with a leading "#" character, but avoid macros (beginning with %) that are potentially multiline (as they are expanded first).
If commenting out a line, double the percent signs (%%). Also avoid inline comments on the same line as a script command.
 
The major tags are listed below. Note that the macros %{name}, %{version} and %{release} can be used to refer to the Name,
Version and Release tags respectively. When you change the tag, the macros automatically update to use the new value.
 
Name: The (base) name of the package, which should match the SPEC file name. 
It must follow the Package Naming Guidelines and generally be lowercase.
Version: The upstream version number. See Version tag section of the packaging guidelines.
If the version contains tags that are non-numeric (contains tags that are not numbers),
you may need to include the additional non-numeric characters in the Release tag.
If upstream uses full dates to distinguish versions, consider using version numbers of the form yy.mm[dd] (e.g. 2008-05-01 becomes 8.05).
 
Release: The initial value should normally be 1%{?dist}. 
Increment the number every time you release a new package for the same version of software. 
When a new upstream version is released, change the Version tag to match and reset the Release number to 1. 
See Release tag section of the packaging guidelines. The optional Dist tag might be useful.
 
Summary: A brief, one-line summary of the package. Use American English. Do not end in a period.
 
Group: This needs to be a pre-existing group, like "Applications/Engineering"; 
run "less /usr/share/doc/rpm-*/GROUPS" to see the complete list. 
Use the group "Documentation" for any sub-packages (e.g. kernel-doc) containing documentation.
 
License: The license, which must be an open source software license. 
Do not use the old Copyright tag. Use a standard abbreviation (e.g. "GPLv2+") and be specific 
(e.g. use "GPLv2+" for GPL version 2 or greater instead of just "GPL" or "GPLv2" where it's true). 
See Licensing and the Licensing Guidelines. 
You can list multiple licenses by combining them with "and" and "or" (e.g. "GPLv2 and BSD").
 
URL: The full URL for more information about the program (e.g. the project website). 
 
Note: This is not where the original source code came from which is meant for the Source0 tag below.
 
Source0: The full URL for the compressed archive containing the (original) pristine source code,
as upstream released it. "Source" is synonymous with "Source0".
If you give a full URL (and you should), its basename will be used when looking in the SOURCES directory.
If possible, embed %{name} and %{version}, so that changes to either will go to the right place.
Preserve timestamps when downloading source files. If there is more than one source, name them Source1,
Source2 and so on. If you're adding whole new files in addition to the pristine sources,
list them as sources after the pristine sources. A copy of each of these sources will be included in any SRPM you create,
unless you specifically direct otherwise. See Source URL for more information on special cases (e.g. revision control).
 
Patch0: The name of the first patch to apply to the source code.
If you need to patch the files after they've been uncompressed,
you should edit the files and save their differences as a "patch" file in your ~/rpmbuild/SOURCES directory.
Patches should make only one logical change each, so it's quite possible to have multiple patch files.
 
BuildArch: If you're packaging files that are architecture-independent (e.g. shell scripts, data files),
then add "BuildArch: noarch". The architecture for the binary RPM will then be "noarch".
 
BuildRoot: This is where files will be "installed" during the %install process (after the %build process).
This is now redundant in Fedora and is only needed for EPEL5. By default, the build root is placed in "%{_topdir}/BUILDROOT/".
 
BuildRequires: A comma-separated list of packages required for building (compiling) the program.
This field can be (and is commonly) repeated on multiple lines. These dependencies are not automatically determined,
so you need to include everything needed to build the program. Some common packages can be omitted, such as gcc.
You can specify a minimum version if necessary (e.g. "ocaml >= 3.08").
If you need the file /EGGS, determine the package that owns it by running "rpm -qf /EGGS".
If you need the program EGGS, determine the package that owns it by running "rpm -qf `which EGGS`".
Keep dependencies to a minimum (e.g. use sed instead of perl if you don't really need perl's abilities),
but beware that some applications permanently disable functions if the associated dependency is not present;
in those cases you may need to include the additional packages. The "auto-br-rpmbuild" command may be helpful.
 
Requires: A comma-separate list of packages that are required when the program is installed.
Note that the BuildRequires tag lists what is required to build the binary RPM,
while the Requires tag lists what is required when installing/running the program;
a package may be in one list or in both. In many cases,
rpmbuild automatically detects dependencies so the Requires tag is not always necessary.
However, you may wish to highlight some specific packages as being required, or they may not be automatically detected.
 
%description: A longer, multi-line description of the program.
Use American English. All lines must be 80 characters or less.
Blank lines indicate a new paragraph. Some graphical user interface installation programs will reformat paragraphs;
lines that start with whitespace will be treated as preformatted text and displayed as is, normally with a fixed-width font.
See RPM Guide.
 
%prep: Script commands to "prepare" the program (e.g. to uncompress it) so that it will be ready for building.
Typically this is just "%setup -q"; a common variation is "%setup -q -n NAME" if the source file unpacks into NAME.
See the %prep section below for more.
 
%build: Script commands to "build" the program (e.g. to compile it) and get it ready for installing. 
The program should come with instructions on how to do this. See the %build section below for more.
 
%check: Script commands to "test" the program. This is run between the %build and %install procedures,
so place it there if you have this section. Often it simply contains "make test" or "make check".
This is separated from %build so that people can skip the self-test if they desire.
 
%install: Script commands to "install" the program. The commands should copy the files from the BUILD directory %{_builddir} into the buildroot directory, %{buildroot}. See the %install section below for more.
 
%clean: Instructions to clean out the build root. Note that this section is now redundant in Fedora and is only necessary for EPEL. Typically this contains only:
rm -rf %{buildroot}
 
%files: The list of files that will be installed. See the %files section below for more.
 
%changelog: Changes in the package. Use the format example above.
 
ExcludeArch: If the package does not successfully compile, build or work on a particular architecture,
list those architectures under this tag.
You can add sections so that code will run when packages are installed or removed on the real system 
(as opposed to just running the %install script, which only does a pseudo-install to the build root).
These are called "scriptlets", and they are usually used to update the running system with information from the package.
See the "Scriptlets" section below for more. RPM also supports the creation of several packages (called subpackages) 
from a single SPEC file, such as name-libs and name-devel packages.
 
Do not use these tags:
 
Packager
Vendor
Copyright
Do not create a "relocatable" package; they don't add value in Fedora and make things more complicated.
rpm.1334255716.txt.gz · Last modified: 2020/08/10 02:29 (external edit)