Version Controlling rpm spec files

Question

I'm configuring a build machine to produce rpms for a large number of very similar projects. The spec file for each project is slightly different, both in name and sometimes in dependencies and other attributes. Each project has its own git repository containing the project files.

These spec files only exist and truthfully are only useful to the build system itself; each project can be installed manually, but I package into rpms for ease of automated deployment.

The build system itself also has its own git repository.

Should the spec files be versioned? And if so, where? Should each spec file be versioned in the repository for the project it correlates with? Or should they all be versioned in the same repository as the build system? And, most importantly, why?

I'm concerned that versioning the specs in project repositories will cause the files to become out of sync with each other as I make gradual improvements to the install process. I'm also concerned that versioning the specs in the build repository will cause the files to be forgotten when changes to dependencies are made.

Answer 1

I'm working a project where we version control the RPM spec files in the same directory tree as the library or project. Why? This keeps everything neatly co-located. When we update a source file in the library, then the spec file is right there to add an appropriate entry to the %changelog, detailing what was done for the bug fix or enhancement.

For your situation, it's a tough call. But I'm thinking your build/install system will eventually reach a stable point, whereas all your projects will doubtless need to be updated at some point to when fixing bugs. Yes, it might be painful in the near-term as you tweak your build/install process, but once that's stabilized, it'll be easier in the long term.