I have a bunch of tools (nagios, munin, puppet, etc...) that gets installed on all my servers. I'm in the process of building a local yum repository. I know most folks just dump all the rpms into a single folder (broken down into the correct path) and then run createrepo inside the directory. However, what would happen if you had to update the rpms?

I ask because I was going to throw each software into its own folder.

Example one, put all packages inside one folder (custom_software)


What I'm thinking of ...


Ths way, if I had to update to the latest version of puppet, I can save manage the files accordingly. I wouldn't know which rpms belong to which software if I threw them into one big folder. Makes sense?

  • yes I could install them from the net, but most of my boxes have internet access disabled to them. Also, I unpackaged and edited most of the config files to some of the packages (no need to edit config file after installation). – luckytaxi Apr 10 '10 at 22:48
  • In most cases, you won't have conflicting RPMs, correct? In your example above, it's unlikely that the Nagios RPMs ever conflict with the Puppet RPMs? – Stefan Lasiewski Sep 24 '10 at 19:10

I believe you need a separate repository, with data generated by createrepo, for each distinct release that you are supporting. This is so you have a catalog that yum knows about via your .repo file. Your first proposed method would allow you this.

Using your second method you'd end up having to create repository data for each package you were maintaining, which seems like a nightmare as far as you would have to have repository data for each package.

Additionally, I wouldn't be building inside of your repository (which is the only reason I can think of for separating it out by software). Set up your build environment with rpmdev-setuptree(available in the rpmdevtoolspackage), build the rpms and copy/move them from the build structure to your repository structure (/<root_repo>/<release>/<arch>/<RPMS/SRPMS>), then generate your repository data via createrepo (or createrepo --update . ) in the release ( 5.4 / 4.6 ) directory.


I think throwing them all into one folder works fine. When you have a new version of a package, toss that in there to, and then use "repomanage" from the yum-utils package to trim out older versions.


Use a mix of both: Create Repos of different types und throw the relevant rpms into these.

For every repo we use a "staging"-variant that contains the newest rpms. If these test out well on test machines thes rpms go to the live repos.

The staging rpms can be automated.


I have everything lumped into one directory. When an update comes out I move the RPM into the directory and remove the old one. Then I run createrepo -v --update /PATH/TO/REPO.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.