Source controlling RPM installer

Question

Can anyone provide guidance on the best way to source control the artifacts that go into building an RPM package? My past experience with installers was on Windows platforms, and in those environments, you'd simply add the installer artifacts such as project files, etc., to source control. However, the RPM building process seems a bit alien to me. For example, a certain directory structure is expected at a certain location on the file system. Should I just add the .spec files to source control? Should I add the whole directory structure? Any guidance here is appreciated. Note that in this particular instance I'm working with Red Hat Enterprise Linux 5 and Fossil SCM, though you can think of the latter as Subversion (SVN) if you're not familiar with it.

Answer 1

Generally the two things you need to produce an RPM are the source code (with patches if appropriate) and the spec file. Producing the rpm build tree can be automated with little effort.

So if it's your software you're building an RPM package for, I'd add the .spec file to an appropriate spot in your tree, and enhance your build automation (e.g. Makefiles) to create the rpm build tree skeleton, populate it with your source, add the .spec file to the SPECS subdir, and issue the rpmbuild commands.

If the software for which you're building the RPM package comes from upstream, I'd check in the .spec file, the upstream tarball, patches, scripts, etc. Then either use their infrastructure for building the RPM, or do as above.