Basically all yum-arch does is digest the rpms that you have in a directory and create a header file for each rpm. That statement is VERY HIGH LEVEL and is not meant to diminish the importance of the yum-arch program. yum-arch is the cornerstone of yum. Without it you may as well stick with rpm.
You will need to run yum-arch as root.
It is important that you create the yum headers in the correct directory. You could, if you wanted to, run yum-arch at the beginning of your repository and create one large header directory of all the rpm headers. You could, but you shouldn't.
The headers directory that you create will have a direct impact on what you will put in your yum.conf file so you will need to think about this carefully. You will have to point yum (via yum.conf) at the directory that has the headers directory in it or yum will not find the headers and not find the packages.
You must make sure that you set out your directory structure clearly and correctly. This just makes thing easier when something goes wrong. It also makes it easier to rsync your local mirror if you replicate the remote servers directory structure.
An example tree in /var/ftp/pub/ could look like this:
/9/
/base/
/athlon
/i386
/i586
/i686
/freshrpms
/fedora
/kde/
/3.1.2
/3.1.3
/rawhide
/updates/
/athlon
/i386
/i586
/i686
root@cartman>yum-arch /var/ftp/pub/9
The directory structure would look as follows:
/9/
/base/
/athlon
/i386
/i586
/i686
/freshrpms
/fedora
/headers # yum-arch creates the headers here.
/kde/
/3.1.2
/3.1.3
/rawhide
/updates/
/athlon
/i386
/i586
/i686
That would work fine but it is not the cleanest way to use yum-arch. There are also issues with some of the newer functionality in yum like groups when all your headers are dumped in one directory.
So a solution would be to run yum-arch against a distinct sub-repository in the repository tree. An example of this is:
root@cartman>yum-arch /var/ftp/pub/9/base
root@cartman>yum-arch /var/ftp/pub/9/freshrpms
root@cartman>yum-arch /var/ftp/pub/9/fedora
etc...
/9/
/base/
/athlon
/headers
/i386
/i586
/i686
/freshrpms/
/headers
/fedora/
/headers
/kde/
/3.1.2
/3.1.3
/headers
/rawhide/
/headers
/updates/
/athlon
/headers
/i386
/i586
/i686
Now that you have created the headers manually you will need to maintain your yum.conf file to point the client at the headers so you can start using yum.
yum-arch has a number of options that can be used to affect the way that the way that the headers are created.
root@cartman>yum-arch [options] directory
root@cartman>yum-arch -d directory
Here is an example of a conflict:
Checking deps 91 % completewarning: package samba-client = 3.0.0-5rc1 was already added, replacing with samba-client <= 3.0.0-5rc1
depcheck: package xmms-devel needs xmms = 1.2.7
This is pretty simple. Delete the oldest rpms from your repository. This should really be done using rsync (as noted above). rsync, used to replicate a remote mirror locally, can be configured to delete local files that do not exist on the remote server.
This may or may not be simple.
If the dependency problem is caused by the required package just not being available on any of the repositories you are mirroring, you will either have to look for the package at rpmfind or (if you have sources or the data that needs to be packaged) build the rpm yourself. Building rpm's is discussed below.
A word of warning: Any packages that are not on the mirrors may be deleted from your local repository by rsync (if you use --delete to maintain a perfect mirror) so you will need to keep these site-local packages in a "local" repository. You have been warned.
If the dependency problem is more complex (and it may be very complex if you have two or more packages from different repositories whose builders used different naming/numbering conventions, or if you have "legacy", possibly proprietary or closed source packages that require old versions of libraries while the rest of your applications require modern libraries) then you will have to work much harder to resolve them. Indeed, in some cases no resolution will be possible -- there are plenty of sites out there that are running "obsolete" linux distributions because one of their mission-critical applications requires the libc or other libraries intertwined with that particular distribution and all its binaries.
Fortunately, just as yum permits one to easily upgrade (so why would one ever need a complex repository tree?) it permits one to easily maintain a complex repository tree, so the solution in the worst cases may well be to maintain separate repository trees for non-conflicted distributions. Sure, it's ugly, but in the open source world (or for that matter the closed source world) one cannot make writers of important packages comply with a common set of rules, one can only hope that they do and deal with it when they don't.
root@cartman>yum-arch -v directory
ignoring older pkg: redhat/9/i386/openssh-askpass-gnome-3.5p1-6.9.i386.rpm
Digesting rpm - openssh-askpass-3.5p1-6.9.i386.rpm - 95/3202
Already found tuple: openssh-askpass i386
ignoring older pkg: redhat/9/i386/openssh-askpass-3.5p1-6.9.i386.rpm
Digesting rpm - openssh-3.5p1-6.9.i386.rpm - 96/3202
Already found tuple: openssh i386
ignoring older pkg: redhat/9/i386/openssh-3.5p1-6.9.i386.rpm
Digesting rpm - openssl096-0.9.6-17.i386.rpm - 97/3202
Digesting rpm - openssl-0.9.7a-5.i386.rpm - 98/3202
Digesting rpm - pam_smb-1.1.6-9.9.i386.rpm - 99/3202
Digesting rpm - php-4.2.2-17.2.i386.rpm - 100/3202
Digesting rpm - php-devel-4.2.2-17.2.i386.rpm - 101/3202
Digesting rpm - php-imap-4.2.2-17.2.i386.rpm - 102/3202
Digesting rpm - php-ldap-4.2.2-17.2.i386.rpm - 103/3202
Digesting rpm - php-manual-4.2.2-17.2.i386.rpm - 104/3202
How much info do you need? Once you are happy that yum-arch is working correctly and generating the correct headers you do not need the output to be verbose. yum-arch is usually run as a cron job so you are not really aware of the output generated. It is good to know that it is there and has helped me to explain some anomalies in the past.
root@cartman>yum-arch -n directory
When checking dependencies, one may not want to actually generate headers. Perhaps one has just added a new package and wants to see if it conflicts, but doesn't want there to be a window where the headers set is "broken" if there are indeed major conflicts. The -n flag permits the automatic generation of headers to be surpressed.
root@cartman>yum-arch -q directory
The -q flag does reduce the amount of information that yum-arch generates but yum-arch will never run totally silent. Any conflicts or redundant packages will be reported to the screen. Once you are happy that yum-arch is doing what you want it to do (ie. the second time you run it) you hould create a cron job that will run yum-arch daily. The -q flag is the best flag to use as yum-arch creates the headers and only tells you about the warnings.
root@cartman>yum-arch -c directory
Hmmmmmm. You are just looking for hassles with this command. I can see its uses but not all packages have an MD5 checksum nor do they have a gpg signature. So if you are security conscious and you are not sure about the packages that you have downloaded then this flag is for you.
[THIS FLAG DOES NOT WORK FOR ME -- jp]
root@cartman>yum-arch -z directory
root@cartman>yum-arch -l directory
root@cartman>yum-arch directory
When you use yum-arch to create the headers for your repository, yum-arch will always produce these two lines at the end of the screen report (except -q):
Total: 3202 #Total packages read
Used: 1521 #Total headers created
That is all you really need to know. What are thee two lines telling me? Basically I need to clean up my repository as more than half of my packages are not having headers created for them. This is normally due to th fact that some of my packages are duplicated in the repository or there are conflicts. This is probably caused by the fact that I have the rawhide packages in my repository. Bleeding edge and all that.