Red Hat FedoraCore4 Up2date Guide

One of the new items added to Up2date in FC4 is the default support for updating any of your Fedora Extra’s packages. Thus, the stock available update channels are updates-released, extras, and base. The first channel we’ll be adding is for a local directory repository. The location to add the channels in is still /etc/sysconfig/rhn/sources; however, the format for this sources file is quite different from the traditional one in FedoraCore3. To the sources file, append dir name-of-repo /location/of/repo. In our instance, we entered dir local-repo /root/up2date-updates/. In the original sources file there is references to a directory repository except they are commented out, so you can simply overwrite the comments or add the line for your directory repository to the end of the file. The interesting thing is that with FedoraCore4 when doing a dir repo we no longer need to get into the directory of these binaries to create a yum distribution database using yum-arch. We simply had all of the RPMs placed in the folder with no other header information.

If you are interested in establishing a LAN Up2date repository, our previous how-to guide continues to hold true for the server side configuration of placing the RPMs in a HTTP directory and then using yum-arch to generate the yum distribution database. However, when it comes to the client-side configuration the URL is identical except it needs to be in the format of yum LAN-repo-name http://IPADDY/fedora/location/ for the sources file, similar to when adding 3rd party repositories.

For adding some 3rd party repositories to Up2date, we used the same sources file that we previously used, of course simply appending a different format instead of the directory type. As most of these 3rd party repositories offer both yum and apt support, we decided to go with yum due to personal preferences. If you’re interested in adding an apt repo simply check out the example in the sources file. For these 3rd party repositories, we chose two of our favorite and most popular – FreshRPMs and Atrpms. We also decided to use the stable directories in this instance rather than the testing alternatives. The lines added were:

yum FreshRPMs-repo http://ayo.freshrpms.net/fedora/linux/$releasever/$ARCH/freshrpms/
yum Atrpms-repo http://apt.atrpms.net/fedora/$releasever/en/$ARCH/at-stable/

Alternatively, the name of the repositories can be changed depending upon personal preference along with, if you prefer to use, the stable selection or un-stable/testing. When downloading updates from the official channels as well as the third party alternatives, we found the time required for testing the package set and solving RPM interdependencies decreased marginally and during this time Up2date was more stable where previously it would crash if too many packages were selected. Retrieving the packages from the dir repo was instantaneous, as it simply had to read the hard drive rather than an external source.

Although Red Hat has improved the quality of Up2date, it still has its share of problems. One of the problems is the GNOME Up2date applet not properly identifying the number of updates that are there to be upgraded. Another such glitch is during the retrieval and installation process with Up2date, the status bars reports the wrong progress. For example, once the updates are all installed, the status bar isn’t entirely filled. Red Hat’s Up2date also has room to improve when it comes to the time required in order to test the package set and solving RPM interdependencies. Nevertheless, Up2date 4.4.23 appears to be much more stable than previous releases although there is still plenty of headroom for improvement. The new format for the Red Hat Network sources file is also very welcome due to the ease of adding additional update channels and other update modifications.