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:
>> On 2011/09/17 01:06, Tanmoy Chatterjee wrote:
>>>
>>> On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcia<[log in to unmask]>
>>>  wrote:
>>>>
>>>> On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjee<[log in to unmask]>
>>>>  wrote:
>>>>>
>>>>> On Fri, Sep 16, 2011 at 10:36 PM, Connie Sieh<[log in to unmask]>  wrote:
>>>>>>
>>>>>> On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote:
>>>>>>
>>>>>>> Is there any difference between Sl6.1 and SL6x repositories? Do I need
>>>>>>> to enable only of these two or both?
>>>>>>
>>>>>> sl6x is a symbolic link to the "current" release.  So at the moment
>>>>>> sl6x
>>>>>> points to sl6.1 since sl6.1 is the current release.  When we release
>>>>>> sl6.2
>>>>>> then sl6x will point to sl6.2 .
>>>>>>
>>>>>> So you need to pick 1 .  If you pick sl6x you will updated via the yum
>>>>>> cron
>>>>>> job to the "next" release when it is released.
>>>>>
>>>>> Thanks for the elaboration - so it is a good idea to enable the SL6x
>>>>> repositories instead of SL6.1.
>>>>
>>>> It's a choice, and it's actually a reasonable one to select 6.1. If
>>>> you follow the model of The Upstream Vendor, the "5.0", "5.1", "5.2"
>>>> releases are all supposed to upgrade in place, automatically, to get
>>>> all current packages. ""6.0" and "6.1" are timestamps for media
>>>> releases, and do not represent a different software repository
>>>> maintained by them. This avoids the amazing pain some of us had to
>>>> deal with for years, back with the original "releases back when their
>>>> old "7.0" and "7.2" releases were likely to be incompatible.
>>>>
>>>> This way works better, by not trying to split support among so many
>>>> sub releases.
>>>>
>>>> Our friendly maintainers at Scientific Linux, understandably, don't
>>>> quite follow that, but with their common "5x" repository, and
>>>> "rolling" releases, it's pretty close. I really appreciate using that
>>>> one or two repositories, instead of having to mix and match from point
>>>> releases.
>>>
>>> Have really got confused after going through your entire post - so I
>>> am asking again - is it better to enable SL6X than SL6.1?
>>
>> At some point you have to accept responsibility for the choice based on
>> your specific needs. If you need a stable system with minimal changes
>> use 6.1. If you can accept a little additional risk and want product
>> updates as they are folded in then select 6.x.
> Actually using Ubuntu 10.04 - I have found automatic upgradation takes
> place via update process and without any problem ( i.e from 10.04.1 -
> 10.04.2 - 10.04.3).
>           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.
>>
>> 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.)
>>
>> 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.
>>
>> {^_^}    Joanne
>>
>