Re: What happened to 6.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Monday, October 31, 2011 12:11 AM, Ljubomir Ljubojevic wrote:
> Vreme: 10/30/2011 03:46 PM, Dennis Jacobfeuerborn piše:
>> On 10/30/2011 02:14 PM, Ljubomir Ljubojevic wrote:
>>> I do not think there is much to be worried for now. Most/all security
>>> patches will come out fairly fast now that CR repo is in place.
>>>
>>> If need be, there can always be another repo that will be reserved for
>>> fast fixes that are not compatible with RHEL, like package with
>>> important fix that is not exactly compatible, but does the job same as
>>> upstream package. This would be only for unresolved packages with
>>> important fix, and only as long as complete fix is not completed.
>>
>> But this approach has been rejected in the past with the argument that all
>> builds need to be binary compatible with upstream.
>> This begs the question if the centos project still considers itself viable?
>> It's one thing to lag behind because of technical difficulties but another
>> if the upstream provider essentially wants to prevent you from doing what
>> you are doing. In that case the project probably doesn't have much of a
>> future because even if it gets back on track with reasonably timely
>> releases then upstream will probably just react by making it even harder to
>> build a clone.
>
> First off, I do NOT speak for dev team.
>
> Next, what I said was if there is a problem with, for example missing
> src rpm for a security fix, and centos team knows what patch was applied
> (looking at the source and bug tracker), then I would be fine with
> alternative package with same patch that would bridge the time until
> upstream provides that src and it is possible to rebuild exact package.

It is not just what patches were applied. It is also what version of the 
toolchains and libraries were used in building the package. That is 
where the main problem is base on what the devs say besides the Redhat 
problem of packages that should not be distributed to others if you want 
to keep your RHN access...


>
> Further, what is exactly difference between going to totally new distro
> and having not-100% compatible distro? Are small and rare differences
> enough to warrant switch of entire distro? I do not think so.

The Centos team wants to do 100% binary compatibility. Then any problem 
is upstream's fault. They are not like Oracle who can afford to leech 
off Redhat and hire their own engineers to do some tinkering on the side 
too.


>
> And what is with all that "I will switch to Ubuntu", "I am switching to
> Ubuntu and all of you better do the same"? Why is there need for
> sensationalism? If you want to go, then go. There is no need to alarm
> other users with doom prophecies. With CR repo (created only month or
> two ago) there is viable way to receive important updates.

+1


>
> If things complicate more on security front, CR can become enabled by
> default or update repo for current minor version will be populated with
> appropriate security fixes (my view, can not say for devs).
>
> I would sincerely like to see number of security updates that are not in
> CR, and number released to CR repo, so we can deal with facts rather
> then "I haven't seen any updates for a while and I am convinced that
> every distro *must* have large number of security updates" mentality.
>
>

Every distro DOES have a large number of security updates. The real 
biggie is how many of them are remote root exploits and for those who 
provide shell access, how many of those are local root/privilege 
exploits. That's a HEALTHY mentality if you have Internet facing boxes 
or you have secrets/confidential stuff that you want to keep from other 
departments/colleagues.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux