fc4 - yum

[Temlakos]

Ted Gervais wrote:
> I  just installed fc4 over fc3 and it went well. But now I am wondering 
> about updating it as time goes by.
> It seems to me that I had to edit the yum.conf or apt.conf files to have 
> the update request go to fc3 files before.
> So it makes sense that maybe I have to edit those files again for the 
> process to go to fc4 updates??
> 
> Does that make sense.  Also, I believe that an upgrade to another fedora 
> release produces or places new configuration files for YUM somewhere on 
> my system?
> Is that true.  And if so, where would that be.
> 
> Thanks for any direction that may be provided to my questions..
> 
> 
> ---
> Ted Gervais,
> Coldbrook, Nova Scotia, Canada
> 

These days, the favorite place to take care of yum repo channels is the 
directory /etc/yum.repos.d/ In there, you place files, each named 
such.repo (replace "such" with a one-word name for each repository you 
want to use), containing repository names, "base url's" (and sometimes a 
  "mirrorlist" url that points to a long list of mirrors), and the 
"enabled" and "gpgcheck" parameters. Putting everything in a big file 
named "yum.conf" is out-of-date now--mostly because those big files are 
much more difficult to manage.

The baseurl and mirrorlist variables accept URL's, but each of those can 
accept variables that substitute values on the fly. The two of interest 
here are:

$releasever	Gives the particular version of Fedora Core that you're 
using. It's literally the number of the version--so for Fedora Core 4, 
it's--well, "4"!

$basearch	Gives the architecture you're using. The value on my machine 
is "i386." On other machines it might be "x64."

The $basearch and $releasever are part of the system environment--maybe 
someone else can tell us where those are set or re-set.

Yum can recognize baseurl's and mirrorlist url's having $releasever and 
$basearch. In that way, the file updates itself to point to the current 
repository. (Warning: if the repo keeper doesn't have his directory 
structure reconfigured, this can return a not-found error. Dag and Axel 
both took a long time to get their directory structures up, and I 
believe Dag has some hardware problems at the moment.)

The only remaining issue is what repo's you can safely mix. The official 
repo set is "base", "updates-released", and "extras". The "livna" repo 
contains packages, compatible with the above repo's, containing software 
that is not exactly "free software," usually for multimedia 
applications. Michael A. Peters now has some excellent repo's, including 
jpackage, that are also compatible with all the above.

The big issue is with the RPMForge repo family (FreshRPMS, Dag, Dries, 
and AT-stable/good/testing/bleeding). They have a wider variety of 
stuff, but they also have stuff that conflicts with the stuff in extras 
and livna. Their relations with the keepers of "extras" have been broken 
for years. So then you have to make a choice between the two 
families--and that might not be easy! Extras has grown by leaps and 
bounds--but if you want your "mythtv", you need Axel's at-stable at 
least, and that could break some of the extras packages.

Unless you use "smart" (http://www.smartpm.org/). "Smart" can set 
priorities among your repo's and thus enable you to use RPMForge repos 
safely together with extras without breaking anything.

At last report, the RPMForge community plans to build one gigantic 
repository from the contents of the four major players.

Temlakos