Lukas Rovensky wrote: > Hi all, > > as promised, I explored the options we have concerning Samba 3.4 x > Mozilla LDAP 6 C SDK. As you can see below there is currently no ideal > solution and a compromise will be needed. From the business point of > view we really would like to be able to put Samba 3.4 to S10U9 -- we are > already getting requests for interoperability with Windows 7, [1] and > again the answer is Samba 3.4. > > 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. > > 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).
The ARC can't answer this for you, this is a business decision based on resources and the risks of S10 and Nevada source trees diverging in this area. The above information is great background but the project team should pick one as their proposal (I think you are saying option 1) and ask the ARC's opinion. -- Darren J Moffat
