--On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak@redhat.com wrote:

I understand that you don't want to support older OpenLDAP versions, builds with non-default libraries, etc. But the users will rather use the package from their distribution, instead of compiling it by themselves. And we cannot support users' builds, because we do not have the sources and the build environment under control. And we cannot rebase the packages freely.

Redhat needs to come up with a solution to this problem, because they are putting their users in a catch-22 situation. Either they get support from RedHat for a package that will not work, or they build their own, and can't get support from RedHat. There are reasons new *patch* level releases are made. I see zero reason why RedHat cannot update the versions of OpenLDAP they ship since the fixes are incremental. No one should be running OpenLDAP 2.4.23 as a *production server*. Keep the RPM version string the same, and note the upstream release in the RPM patchlevel, if that is necessary, but fix the actual code to be current.

This is why the Debian folks *wisely* recommend that people do *not* use the distribution build for a production server.

As long as RedHat keeps up this policy, the only advice ever for RedHat customers is to build their own RPMs, and get support elsewhere, since RedHat clearly can't keep working server versions together for their customers. And then that leads to the question of what exactly they are paying RedHat for support for in the first place.

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration