Just to reiterate the Naming sustaining view: We would favour in no particular order:
- NV: OpenLDAP, S10: private Mozilla LDAP (option 2) - NV: true /usr/lib/libldap.so.6, S10: private Mozilla LDAP) > Here is a list of options, which were discussed off-channel -- any > feedback is welcome: > > 1) Leave the PSARC case as it is and ask PSARC members for the vote and > opinion as mentioned by Darren. This is currently the preferred option > by the I-team. > > 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla > LDAP 6 C SDK as Samba's private component in S10. This will have a > clear disadvantage of having different Samba's in S10 and Nevada. Any > LDAP related issue will have to be solved separately for Nevada and S10 > and the maintenance cost will increase. > > 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri > can still help with the integration but we will need a commitment from > the Naming folks that they will support this component (at least on > level C). The LDAP 6 C SDK still shall be Samba's private component in > S10. However, based on the discussion with Naming engineers this would > basically mean an LDAP C SDK update in Nevada, a separate PSARC case > will be required and such solution will certainly take longer than the > time frame we have for S10U9. Besides, we still may have a problem with > getting resources from the Naming team to assist with this task. We'd be better off having a true libldap.so.6 in Nevada than have both libldap.so.5 as we have now and a public/supported Mozilla LDAP 6 in parallel. > 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in > Nevada but will represent a problem for S10. As per the experiments > performed by Jiri -- integration of OpenLDAP to S10 (as private Samba's > component) is not trivial and this will also mean to integrate much > bigger beast than just the LDAP C SDK. OpenLDAP is being changed rather > often, so this will also bring an additional burden for the I-team to > maintain it as part of Samba in S10. We will have a problem to find > resources to do this work (both in terms of people and time). Option 4 looks to be the least favourable. -- Peter
