How to Build Custom Yum Repository

This article builds on the article submitted by Hal Canary
How to make a local yum repository mirror. This article can be used
in conjunction with the aforementioned article, or on it's own in it's own right.
Why is there a need to build a custom yum repository? I think this question is really
quite easy to answer, whilst the vast majority of your requirements will be met by
the standard released rpms, be them the base rpms or updates, there are some which
quite simply are not supplied as standard, or those that are available from Red Hat
/Fedora need to be customized. So how do you ensure that your non-standard rpms
are updated across your managed systems, a simple answer is to use yum.

Step 1. Create Or Obtain Your Non-Standard RPMS

Using the article
Upgrading MySQL version 3 to 4 RedHat / Fedora as a base. We will build
a MySQL rpm, and customized php rpms. We will not go into
the mechanics of creating these custom rpms. We are using the MySQL
example as this provides an example of a new non Red Hat distributed rpm
and some customized verions of Red Hat distributed rpms.

Note:
If the rpms are completely separate from those distributed by Red Hat
then the Release line in the source rpms spec file can be left as
the default value, however, if you are modifying the rpm of a Red Hat
distributed rpm you must alter the Release line of the spec
from say 1 to 1.MY4 before rebuilding the rpm using the
spec file.

Step 2. Create The Yum Repository Directory Structure

You now have access to some customized or new rpms that you wish to distribute
system wide, and you have decided that the best way to do this is to use yum.
You now need to decide on the directory structure that you wish to use.
The set up that will be designed here is one in which the yum repository will be
accessed via a web server. hence the directory structure used will be/var/www/html/fedora/linux/custom/updates/1/i386

Step 3. Populate The Custom Yum Repository

Once the yum repository directory tree has been created, simply copy your custom
and non Red Hat distributed rpms into this directory.

Step 4. Yumify The Directory

Even though all the rpms that we require are now in our new custom yum directory
they are still unusable through yum as it currently stands, basically we are still
missing the headers. To create the required headers simply
issue the following command:

yum-arch /var/www/html/fedora/linux/custom/updates/1/i386 [ENTER]

Issuing the above command will produce output similar to that shown below:

Step 5. Configuring The Clients' yum.conf

The only configuration step left to take, is to ensure the systems that you wish
to use the repository are configured to do so. This is a relatively simple task,
all that is required is that the following is inserted into /etc/yum.conf

Step 6. Further Configuration

As can be seen, combining this mini-tutorial, with Hal Canary's
howto, illustrates how you can also minimize your own bandwith usage, by having your
own onsite yum mirror that is synchronized once every 24 hours, when your bandwith
use is at it's minimum. Your systems then use your local mirror, along with your
local custom rpm yum repository for updates.

Gotcha's

As you are now aware this is a very simple implementation, however you must take
into account the follwing:

If using customized Red Hat distributed rpms, you need to ensure
that you rebuild any updated rpms from source to match your installation,
including editing the Release: entry in the spec file.
Otherwise when yum update is executed, you run the risk of
damaging your client systems setup. Taking the MySQL 4 example,
if new php rpms are released, and your systems have your customized
php-mysql rpm installed, if your systems update using Red Hat's
distributed rpm, your MySQLinstall will be downgraded
back to version 3

When you add new rpms to your custom yum repository, you must re-run the
yum-arch command, otherwise yum will not pick up these newly added rpms