On Wed, Sep 16, 2009 at 11:54:01AM -0500, Johnny Hughes wrote:

That is because we bowed to pressure and released the "security updates" before the other items in 5.4.

Will "normal" users pick these up in their standard "yum update" process?

If so... Oh dear. I think you listened to a vocal minority that wanted to change the existing process. There could easily have been a silent majority who were... OK (not happy, but OK) with the existing process.

Yes, ideally, patches being released ASAP is good. However, not at the expense of stability.

I was one of the silent ones because I recognise the problems with dependency management. I was hoping for a reduced release delay (so 5.4 came out closer to the RedHat release) rather than out-of-order patch releases.

Please reconsider this policy!

This can cause issues with some installs, and we don't really like doing it this way, BUT it is what some people really wanted

Suggestion: "early-patch" repository for those who want security patches before the next point release is available and can't wait.

Le 16 sept. 2009 à 16:58, Karanbir Singh a écrit :

On 09/16/2009 03:33 PM, Miguel Sanchez wrote:

...

My openais version is openais-0.80.3-22.el5_3.9. Their sources don't have that function defined.

so, this is good feedback!

I can push out the newer openais if that fix's the issues here. Can you report this at bugs.centos.org ? lets test and push fix's from there.

-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

In fact several errata today have been issued. Theses errata are recompiled for Centos from RHEL 5.4 errata.

They are not supposed to be installed on Centos 5.3 because of dependency issues (one you have flagged is openais versus cman, but they are probably others also, for example between the new kernel and other parts of Centos like nfs, ext3, ext4, ...).

Since currently Centos 5.4 is not avail, theses updates should probably not have been issued.

Now that they are, I hope all the packages of Centos 5.4 will be made avail soon.

Regards,

On 09/16/2009 05:52 PM, Alain RICHARD wrote:

Now that they are, I hope all the packages of Centos 5.4 will be made avail soon.

no they wont be available before 5.4 itself is released.

however, whatever specific problems people might find - we will try and fix. the openais and nfs ones might be trivial. There havent been any others reported. And the openais one hasent even been put into bugs.centos.org!

Le 16 sept. 2009 à 22:51, Karanbir Singh a écrit :

On 09/16/2009 03:33 PM, Miguel Sanchez wrote:

...

Hi. Today I have updated my cluster installation with the version cman-2.0.115-1 through yum update. When I have started the cman service , it fails.

I've added this issue : http://bugs.centos.org/view.php?id=3842

And published openais packages that should address the issue, could someone with the issue test those and let us know asap.

Reporting back on the issue tracker > reporting back on the mailing list

thanks

-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Sorry, but I wont test that : all my cman servers are part of clusters in production and I will not do any test with part of packages being 5.3 based and other 5.4 based because it means I am doing the QA stuff under in product environments.

We are using Centos because it is synchronised with the QA process of the upstream enterprise.

With your new policie, we now have several cases :

A) Release x.y that is sync with upstream

we only drawback for me is that there is 1-3 days of delay between the release of a patch from upstream and the integration into centos. But for most of us this is OK. If not, we can always buy the original product from upstream.

B) Release x.(y+1) from upstream, not yet validated under centos

When upstream create a dot subversion, there is always a long time (10-90 days) in order for the centos project to recompile and revalidate all the packages and process. This is a well known issue of this process and I hope we can stay under 30 days if possible in order to keep the credibility of the project, and it seams there are some improvements under way to keep this goal.

In that case, there is a gap of 10 to 90 days under which several security patches may be issued but not installed under our Centos servers. Once more, if we want the real upstream support, we have to buy it from upstream and not complain from centos.

Once centos issue the new x.(y+1) version, we are back in case A).

C) The new policy of centos x.y + security patches of upstream x.(y+1)

In that case, we are in a situation where the system is not a x.y version and not a x.(y+1) version.

At least we may get dependencies issues (for example cman/openais case), but also stability issues (for example new kernel with older user land tools).

We get a system that is not in sync with upstream QA (the main reason people choose Centos is to be in sync with upstream QA without paying for it !).

I understand that issuing the patches of upstream x.(y+1) to be installed under centos x.y is an attempts to close the gap of case B).

But the problem is that the way you have done it will move all people from a well known state (A) to an unkown state (C) without warning.

I think a better approach would have been to propose theses new security patch under an optional repository and not the update one.

And don't misunderstand : I am very pleased with centos, and I just add my 2 cents in order to improve it !

Regards,