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
