RPM

From OPeNDAP Documentation
Revision as of 19:21, 11 September 2013 by Jimg (talk | contribs) (→‎Procedure)
⧼opendap2-jumptonavigation⧽

<< back to HowTo Guides

About Building RPMs

Once a release is made, it's time to make the binaries.

The owner of a project is responsible for the source distribution and most of the binaries. Everyone should be able to make Linux binaries. For OS/X and Win32, if you have those platforms, build the binaries. If not, ask someone to help or post to the opendap-tech list and see if we can get a contributed binary.

About RPMs

Documentation for RPM and rpmbuild, in particular is hard to come by. Here's some good information: Fedora RPM Guidelines

How to configure RPM

Here's how to set up RPM so builds of RPM files are easier to make. This means that you do not have to be root to build the packages. Unless you're using a VM, that's important because running rpm installs when the packages' .spec files are broken can corrupt RPMs databases, making future builds very hard.

First, create a `.rpmmacros` file in your home directory that sets `rpm` to use a set of directories in your own home directory so you don't have to use root privileges when you run `make rpm`. Here's a sample of what you add to the file:

%_topdir /home/jimg/rpm %_tmppath /home/jimg/rpm/tmp

Next, copy the directory structure found under `/usr/src/redhat` being careful to not copy all the files under the `BUILD` subdirectory (BUILD can become substantial over time, so take care to copy the directory structure and not any .rpm files in them).

Procedure

  1. When a release is ready, follow the steps in [wiki:ReleaseGuide the release guide] for making a source release
  2. Make sure that Everyone in the project knows about the release. That's generally all the people that come to the developer's telecon but should definitely include whoever is writing docs for the group. This step is important so that we can keep our documentation up to date.
  3. Make binaries.
  4. To make RPMs for Linux:
    • When you're building things like libdap or the hdf4_handler, make sure that all of the dependencies are satisfied using RPMs and not source builds! This is a pain, but it's how RPM works. Using a mix of binary and source builds is OK if you're not distributing the result, but since we are distributing the result, it's not OK.
      • Make a tar.gz source distributions using make dist or make distcheck. Either use the source dist or check out the tagged code from SVN using export.
      • Use the rpm target in the Makefile.am or, if that's missing use rpmbuild -tb <<tar.gz>>, to make the actual RPM files.
        Potential issues:
        • One gotcha is that the tar.gz file is needed to run rpmbuild when using the -t option. It's best to list dist as a dependency for rpm in the Makefile.am.
        • The spec file must be included in the tar.gz file! If it's not (add it to the EXTRA_DIST variable in Makefile.am) rpmbuild will return a message saying that "Name field must be present in package: (main package)".
        • . The error messages from rpmbuild can be somewhat inscrutable. If you are getting an error and you just have no clue, Google the double quoted error message string since it's likely someone else has had the same problem.
      • You'll probably need to be root to do this. But don't, set up a .rpmmacros file and configure rpm to use an alternative set of directories. You'll then need to mirror the directories in /usr/src/redhat somewhere (e.g., under $HOME). See the explanation above.
      • It might be that you have to install a package (e.g. libdap) to build another (libnc-dap). If so, make sure to remove it once you're done, esp. on a development machine. Leaving a package installed makes it much more likely that package's files will wind up as 'required' by other packages (like libdap.so.6 requiring libdap.so.4).
  5. Transfer the binaries to the web site. They go under /pub/binary. Each group of files for a given version should go in a subdirectory named for that version. As of 15 April 2008, we're not doing that, but we should since it will make the pages lots easier to maintain (moving the old versions to the `old` subdirectory means the old links have to be updated on all of the pages). Also, it makes it confusing for users when we do a release in steps unless they pay attention to the version numbers on the rpm files.