On Mon, 19 Sep 2011, Nico Kadel-Garcia wrote:
On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee <[email protected]> wrot=
e:
On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee <[email protected]> wr=
ote:
On Sat, Sep 17, 2011 at 1:48 PM, jdow <[email protected]> wrote:
=A0 =A0 =A0 =A0 =A0 This method here is different! Now if I enable SL6.1
repositories only - then when the SL6.2 repo gets available - will it
be available through the gui "SL addons > yum.. > " or the method is
different ?
THANKS FOR ALL THE RESPONSES.
But as a novice I would again request to shed some light on this part
of my queries.
You have to pick. If you follow the upstream vendor's model, you use
the "6.x" repository, and the updates to 6.2 will be automatically
available. Whether you *install* them is your choice, but they'll be
available. I recommend doing so.
If you use the "6.1" repository, you'll get some updates for a while,
You will get security updates for the full period that security updates
are available for the 6 release.
but it will be unsupported in the relatively new feature. It is *not
It is not unsupported. You will get security updates but will not get the
new features for each of the new point releases.
feasible* to maintain independent sets of backports to all the minor
OS updates, the testing would be nightmarish, and upgrades of one
component for 6.2 might require other individual upgrades not in 6.0
or 6.1. Trying to maintain the multiple subreleases was a nightmare
back in the old "Red Hat 6.0 through Red Hat 6.2" days of the freeware
Red Hat releases, not RHEL or Scientific Linux or CentOS. Prying old,
dead libraries out of the clawing grips of developers or "high
availability" experts who preferred to say "oh, it's stable, no need
for updates" and "it's my machine, don't you worry about it" was a
source of incredible pain when they then came to me and groused about
our network, storage, and open source integration issues when they
refused to allow basic upgrades.
I recently went through this with Subversion, and it was *painful*.
On my machine here I have two very demanding customers, me and my partn=
er.
I kept it on 6.0 until the VM version I have looked stable with 6.1 and
there were no complaints. So I moved to 6.1 on the firewall machine. It
promptly tossed its X11 cookies with either nouveau (which I had setup
and working on 6.0) and nVidia drivers which I tried in frustration. Th=
e
next kernel update fixed the problem. (I was able to work around it sin=
ce
I mostly administer from command-line anyway. And "startx" worked if I
told it to use a display other than the first one.)
Yeah, NVidia is an open source problem.
So moving from 6.1 to 6.2 MIGHT cause problems that sticking with 6.1
and security updates only might avoid. But, then, it might not. What
level of risk are you willing to take, very low or very very low? That
I can go up until that point when it becomes essential to reinstall
the entire system.
Then the very reason of installing SL ( instead of Fedora or similar
distributions with 6 month release cycle) gets diluted.
is your call to make. You're you and I'm me. We face different demands.
Thanks.
Heads up. The longer you wait, the larger the likelihood of problems.
Relatively frequent updates encourage the use of the supported
configuration options, such as using /etc/sysconfig/[servicename],
rather than hand-editing /etc/rc.d/init.d/[servicename] scripts and
manually installing Perl modules direct from CPAN. And don't *get* me
started on what the proprietary NVidia drivers do to the OpenGL
libraries, except to say that they replace them with symlinks and
don't mention it to the RPM system.
-Connie Sieh
