Difference between revisions of "RPMS"

From Atomicorp Wiki
Jump to: navigation, search
(SPEC: automatically add in the date to a changelog)
(SPEC: Conditional Statements)
Line 61: Line 61:
 
Example 1: an if someversion, else  (new way)
 
Example 1: an if someversion, else  (new way)
  
%if 0%{?el3}%{?el4}
+
%if 0%{?el3}%{?el4}
BuildRequires: somepackage
+
BuildRequires: somepackage
%else
+
%else
BuildRequires: someotherpackage
+
BuildRequires: someotherpackage
  
  
 
Example 2: Specific version (old way)
 
Example 2: Specific version (old way)
  
%{?fc4:BuildRequires: libpcap }
+
%{?fc4:BuildRequires: libpcap }
 
+
  
 
== SPEC: automatically add in the date to a changelog ==
 
== SPEC: automatically add in the date to a changelog ==

Revision as of 16:22, 17 November 2008

Contents

Abstract

A src.rpm is completely self contained, it has everything internal to it to archive, patch, build, and install a piece of software. It also contains macros to run actions before, and after the package is installed, and trigger macros to run before/after its installed when it detects other packages. The action of building an RPM will never involve you installing the package as a requirement to build it.


PSA App Vault RPMS

What makes app vault rpms unique is that you are in effect packaging something for another package management system. That involves more steps, and more changes that have nothing to do with the RPM system. IE, they have their own XML file used to describe the application, and its dependencies.


So here are some tips on building a package that is maintainable:

1) dont ever modify the application tarball directly. Use patches instead, even if it takes you an extra hour to do it right. When you update your rpm in a few months, its going to save you a lot of time.

2) leverage the %install macro if you've got to move files around. This is especially handy since the PSA app vault packages rebundle the web app as httpdocs.tar. Dont waste time doing that up front, when you do it in %install it will make your life a lot easier on the next update.

3) Try to avoid using the Epoch: tag (this overrides the version #). I went Epoch crazy early on, and its coming back to haunt me now. Only use the Epoch tag when all other options have been exhausted.

4) When you're building binary RPMs (not app vault), check out mock. It builds a chrooted OS for whatever platform you need to build packages for. This is useful in that it keeps your build tree away from your production OS.

5) Dont make rpms interactive. Avoid any output, special commands, documentation, that get displayed during the installation. If its being run through yum, a web interface, etc. Odds are noone will see it anyway, and worst case, it could break those apps.


building rpms with rpmbuild

1) Build as yourself. Not root, you'll need to do some work first. Start with your ~/.rpmmacros file

 vim ~/.rpmmacros

2) Add path to build dirs

 %_topdir               /home/sshinn/src/redhat/

3) Create your builddirs

 mkdir -p ~/src/redhat
 cd ~/src/redhat
 mkdir RPMS SPECS SOURCES BUILD SRPMS 
 cd RPMS
 mkdir i386 i686 x86_64

4) Build stuff, example:

 rpmbuild --rebuild whatever-1.0-1.src.rpm

building rpms with mock

 mock -r <DISTRO> whatever.src.rpm

On my system, Ive called my /etc/mock/ configs el4-i386.cfg, el5-x86_64.cfg, so the way I run it is:

 mock -r el4-i386 whatever.src.rpm

I also wrote a wrapper around Mock to rapidly build packages for multiple platforms called "art-build". Its loosely based on Dag Wieers DAR package (pre-mock builder), so instead of building from the src.rpm, I build from the .spec file. You can see art-build here: http://www.atomicorp.com/Tutorials/Building%20RPMS/

Modifying RPMS

SPEC: Conditional Statements

Example 1: an if someversion, else (new way)

%if 0%{?el3}%{?el4}
BuildRequires: somepackage
%else
BuildRequires: someotherpackage


Example 2: Specific version (old way)

%{?fc4:BuildRequires: libpcap }

SPEC: automatically add in the date to a changelog

%define date    %(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} PLD Team  <feedback@pld-linux.org>
Personal tools