On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee <[log in to unmask]> wrote:
> On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee <[log in to unmask]> wrote:
>> On Sat, Sep 17, 2011 at 1:48 PM, jdow <[log in to unmask]> wrote:

>>           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,
but it will be unsupported in the relatively new feature. It is *not
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 partner.
>>> 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. The
>>> next kernel update fixed the problem. (I was able to work around it since
>>> 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.