On Mon, 19 Sep 2011, Nico Kadel-Garcia wrote:

> On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee <[log in to unmask]> wrot=
> e:
>> On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee <[log in to unmask]> wr=
> ote:
>>> On Sat, Sep 17, 2011 at 1:48 PM, jdow <[log in to unmask]> 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