A binary RPM is built off of what is called a "spec" file, which at its most basic contains information about the software package and the files which comprise that package. Some variables are used within a spec file, and those variables are defined within the ~/.rpmmacros file. Below is the .rpmmacros file used when building the custom RPMs included with UBLinux.
Note that all the paths defined are in relation to a RPMBUILD directory, which is within your home directory. If you redefine any of these variables, ensure that you have full write access to all directories referenced.%packager David W. Aquilina %distribution UBLinux %vendor University at Buffalo %_signature gpg %_gpg_path ~/.gnupg %_gpg_name CIT Linux Support%_gpgbin /usr/bin/gpg %_topdir %(echo $HOME)/RPMBUILD %_tmppath %{_topdir}/tmp %_builddir %{_tmppath} %_rpmtopdir %{_topdir}/%{name} %_sourcedir %{_rpmtopdir} %_specdir %{_topdir}/SPECS %_rpmdir %{_topdir}/RPMS %_srcrpmdir %{_topdir}/SRPMS %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
Note that before you begin to build an RPM, the directories referenced by the .rpmmacros file must exist.
The spec file contains various useful pieces of information, including: the name of the program, who packaged the program, contact information, and a description of the program. All of this information is contained within the first part of the spec file, which is fairly self-explanatory. The spec file for the Mulberry RPM is used as an example throughout this document.
Summary: Mulberry Graphical E-Mail Client Name: mulberry Version: 3.1 Release: ub1 Group: Applications/Mail Copyright: Copyright Cyrusoft 1995 - 2003 URL: http://www.cit.buffalo.edu/mulberry/ Packager: David W. Aquilina,BuildRoot: %_topdir/%{name} BuildArch: i386 %description RPM to install Mulberry in a user-friendly fashion. This release of Mulberry has been customized for use with the University at Buffalo mail servers and is only usable by persons with UB IT Names. Mulberry includes support for IMAP, LDAP, and IMSP
Things to note specific to building RPMs at UB:
The BuildRoot is a fake filesystem root ("/") to use when assembling the files to include in the RPM. The real directory structure must exist inside the build root. For example, if you want to install the file /usr/share/applications/mulberry.desktop, you should place the file within ~/RPMBUILD/mulberry/usr/share/applications/ on your build system.
The second part of the spec file is where the actual things get done. We skipp many possible fields here as we're only repacking files into a binary RPM, and do not compile anything from source.
%files %defattr(-,root,root) /usr/local/mulberry /usr/share/applications/mulberry.desktop /usr/share/pixmaps/mulberry.png /usr/share/pixmaps/mulberry.xpm %post ln -s /usr/local/mulberry/bin/mulberry /usr/local/bin/mulberry mkdir -p /usr/local/lib/mulberry/Plug-ins ln -s /usr/local/mulberry/lib/Plug-ins /usr/local/lib/mulberry/Plug-ins %postun rm /usr/local/bin/mulberry rm -r /usr/local/lib/mulberry
The next sections, %files, is the most important. This lists files to include in the RPM. Before building the RPM, these files should exist on the build system within the directory which has been defined as the BuildRoot. %defattr defines the default permissions and ownership of all files within the RPM: - indicates that the permissions should remain as they are on the build system, root,root indicates that the owner and group of the files should be set to root.
These files will also be deleted when the RPM is uninstalled
The %post section contains commands to run after installing the RPM. These commands are run with superuser privileges. The %postun section contains commands to be run after uninstalling the RPM. Again, these commands are executed with superuser privileges.
In the Acrobat RPM, we use the %post section to execute a line of perl to search the /etc/mailcap file for instances of xpdf, and replace it with acroread. We do the reverse in the %postun section.
NOTE: You cannot easily place files in a user's home directory using an RPM. We actually don't try to do it at all. The %post section can contain as elaborate as a shell script you desire, however. For full information on all the possible sections of a spec file (we only use a couple sections as what we're doing isn't that elaborate) see the Maximum RPM book, http://www.redhat.com/docs/books/max-rpm/max-rpm-html/
Reasonably current copies of the spec files which we used are available here: http://wings.buffalo.edu/computing/ublinux/specfiles.
First, you need to have a public/private keypair. This can be generated with gpg using 'gpg --gen-key'. Refer to the UBLinux GPG Key Information (DCE Protected, Restricted Access) for information on obtaining the GPG keys used for UBLinux.
In order for RPM to verify the signature on any packages we produce, it has to have the public key. Use the command sudo rpm --import citlinuxkey.pub.asc to tell RPM about the key. Note that we include this key with UBLinux.
Before we can actually sign any RPMs, rpm needs to know about the key location/ key username. Add these lines to ~/.rpmmacros, if they do not already exist:
%_signature gpg %_gpg_path ~/.gnupg %_gpg_name CIT Linux Support <ublinux-support@buffalo.edu> %_gpgbin /usr/bin/gpg
Note that this assumes you have the CIT Linux keys imported into your personal keyring. A better way to do this might/probably exists.
To add a signature to an extisting package, use the command rpm --addsign /path/to/package.rpm To sign in the process of building a package, use rpmbuild -bb --sign
To check the signature on a package, use rpm --checksig. The output should look like this:
[dwa2@bombadil RPMS]$ rpm --checksig mulberry-3.1-ub1.i386.rpm mulberry-3.1-ub1.i386.rpm: (sha1) dsa sha1 md5 gpg OK
Building RPM Packages (from The Fedora Project)