On 05/25/2011 07:13 AM, Nico Kadel-Garcia wrote:
On Wed, May 25, 2011 at 3:31 AM, Marc Muehlfeld
<[email protected]> wrote:
Hi,
we're currently evaluating a migration from Centos 5 to SL6. But I have some
questions about repositories:
We have a local repository were our servers get their updates from. But I'm
unsure, what I exaclty have to mirror. On the FTP there are the following
directories:
- 6
- 6.0
- 6rolling
- 6x
Question 1: What are the differences?
Question 2: The default *.repo uses the $releasever variable, which is
resolved to "6.0". If we plan to always have the newest (minor) version
after every update, I think I have to replace that. Is there an other
variable for that or do I have to hardcode it?
Question 3: Do I have to block any package that would recreate the SL repo
files after an upgrade?
Don't knock yourself out. Like RHEL and CentOS, if you simply continue
with updates, your "$releasever" will be updated automatically when SL
6.1 is released, and if you look inside the "6x" directory on an FTP
or rsync server, you'll see that it has symlinks to the "6" and "6x"
directories. you'll see that they have symlinks to the "6.0"
directory. Those will be updated when SL does a 6.1 release. The
effect is overall similar to, and more transparent than, what RHEL's
use of the "yum-rhn-plugin" does.
Hi,
This is where SL differs from both RHEL and CentOS.
We do not force you to update to the latest release.
If a person installs SL 6.0, they will stay at SL 6.0, only getting the
security errata, until they wish to update.
And then they don't have to update to the latest either. They can
update to 6.2 even though we are at 6.5.
This was done for the scientists, but I've seen plenty of non-scientists
like this feature (and many that don't). This allows people to sit on a
release an not worry about some feature breaking their program.
In fact, RedHat even started allowing people to do this, for an extra fee.
Troy
--
__________________________________________________
Troy Dawson [email protected] (630)840-6468
Fermilab ComputingDivision/SCF/FEF/SLSMS Group
__________________________________________________
