>> I will note that Mandriva, at least, continually updates the
>> of OpenLDAP they ship, unlike most distributions, so it definitely
>> isn't all. And my point is, Red Hat could do better, and I'd like to
>> see them do better. I'd like to see Debian/Ubuntu do better too.
>> I.e., this isn't specific to Red Hat, but the discussion here is about
>> Red Hat, and what it can do. I discuss Debian and what it can do
>> better with the Debian devs on their openldap dev list.
> Then I'd like to hear what Jan and the other Red Hat OpenLDAP
> maintainers have to say.
As for Fedora, I usualy rebase the package immediately when the new upstream
version is available. And I do it in the stable and newer releases (for today
it would be stable F17, alpha F18, and Rawhide). And if there is a problem in
older Fedora, I just pick the patch.
So we are definitelly not behind with Fedora -- the last submitted updates can
be found here: https://admin.fedoraproject.org/updates/search/openldap
As for RHEL it is more complicated, the rebases are allowed rarely. We cannot
afford any API/ABI breakage and regressions. and I can imagine that a new
feature in OpenLDAP changes the current behavior or affects some other
I can remind a bug which appeared after rebase to 2.4.31 in Fedora and we do
not want to cause a similar problems in RHEL:
I would like to see newer OpenLDAP in RHEL because it would be easier for me
to maintain it. But I'm not sure if the advantages will outweight the
disadvantages and if our customers will benefit from it rather than be forced
to deal with new problems.
Ok. One thing I do with Debian is help triage issues that are
there with the upstream ITS system if the issues do not appear to be due to
the usage of an old version. If there is a simple way to do that with Red
Hat, I could help there as well.
When there is a new bug report, I usualy try to reproduce with the package
from RHEL or Fedora. And then with the newest OpenLDAP from git master. If I'm
able to reproduce, I always create a report in your ITS.