I don't think this is a good idea at present ... until we can guarantee
that a typical ldap directory will work after an upgrade, I don't think it
should go in a commonly-used urpmi medium.
Understand. The upgrade I tried to do sort of worked, but I was having a problem with system passwords syncing and being updated with ldap. (This worked under the recompile of 2.0.27 without-sasl).
Also, I am still learning ldap (so that can't have helped).
My desktop works fine, but I haven't rebuilt too many desktop apps yet.
BTW, I will investigate the auxiliary objectclass account which is in
pam_ldap, and see what can be done about getting in into openldap (I would
guess it should go back into the schema file it was in for 2.0.x).
I was concerned that pam_ldap may have had something to do with my issues, but only found a few leads. I have rebuilt Oden's openldap 2.1.20 (wasn't sure what sasl2 he compiled against). Am in the process of installing & configuring - will let you know how everything goes.
I will take a look at updating Oden's package this weekend, and then give
it a test on some data, and then we can consider putting it into cooker,
and a bit later into club testing.
Cool, no problem with that. Wouldn't that also mean that db41 would have to go into club? Does that create any additional issues?
Just thinking of the (ongoing) sasl -> sasl2 thing. Would the same issues be present in using db40 & db41?
In terms of release numbers etc, I normally decrement (ie 1mdk->0.9mdk as I did with kdirstat) the release when it goes into Club, so that we are guaranteed the next release will update the Club package (even if the cooker package is never updated again).
Makes sense to me.
Thanks,
S
