The answer is not as simple as sticking an RPM with a newer revision in the repo.
There are things to be done on the server side and on the client side.
Server Side
- Copy RPM to repo
- cd /path/to/repo (let's assume /var/www/html/repo)
sudo createrepo --update .
This will update the repo's database to include the new RPM
sudo chmod -R ugo+rX /var/www/html/repo/
This will make the new RPM visible
Client Side
sudo yum clean all
This will get rid off all the cached info related to the repo.
sudo yum info rpmname
You should now see that the latest rpm version is available.
sudo yum -y update rpmname
You should be updated.
I got very frustrated with all the answers (here, there, and everywhere) that glossed over all of these details. Anyone going through the process of creating a repo with updates is going to test it. The test will go like this:
Server Side, Add new RPM to repository, run createrepo, change permissions
Client Side, yum -y install rpmname.
User, "Cool it worked. Now let's try doing and update."
Server Side, Add RPM with newer revision, run createrepo, change permissions
Client Side, yum -y upgrade rpmname, "No Packages marked for Update"
User, "What the #?!@ I just followed all of the instructions I found on the web and this didn't work!"
On the client side, yum will cache information about the repository including the newest available release. The next time the client does an update
or info
command yum will not go back to the internet and check the repository. Yum will use the cached version of the repo.