My current build of samba44 stops in the configure phase. This is a detail of the log: =======================<phase: configure >============================ ===> samba44-4.4.8 cannot install: SASL support requested and openldap-client-2.4.44 is installed. *** Error code 1 Stop. make: stopped in /usr/ports/net/samba44
Replace your openldap24-client with openldap24-sasl-client. For example: portmaster -o net/openldap24-sasl-client net/openldap24-client
Created attachment 178372 [details] Poudriere build log on 10.3-R I get the same error - attaching full build log. The dependency on popt in turn depends on ldb which depends on the normal openldap24-client, so the latter gets pulled in before the samba44 build tries to pull in openldap24-sasl-client using WANT_OPENLDAP_SASL. This seems tricky to solve for those that use packages.
Same problem here with poudriere, on both 9.3 and 10.3, my builds ends with: ===> samba44-4.4.8 depends on shared library: libldap-2.4.so.2 - found (/usr/local/lib/libldap-2.4.so.2) ===> samba44-4.4.8 cannot install: SASL support requested and openldap-client-2.4.44 is installed. AND on freebsd-pkg-fallout mailing list: https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg395669.html
(In reply to Bengt Ahlgren from comment #2) Minor tweak the comment 2... ldb depends on popt, not the other way around. But the main point in comment 2 (and comment 3) still stands. When pulling in packages when resolving samba44's dependencies, if you pull ldb (and its deps) first before pulling in openldap24-sasl-client, you will have trouble. Somehow, the dependency solver used when installing samba44's dependent packages needs to try to pull in the version of ldap client library samba44 needs (openldap24-sasl-client) first before another dependency (ldb in this case) pulls in a version of ldap client library that satisifies its needs but may not be the version that a higher package (e.g., samba44 in this case) wants. ldb will be happy with either openldap24-client or openldap24-sasl-client. But samba44 (which wants ldb) is only happy with the latter. I don't know the right way to fix this in the new pkg world - whether it's a multi-pass dependency solver that's smarter or some other way to more explicitly reference a dependency ordering. Or something else. I am guessing this isn't the first time this problem has appeared - maybe a question to the pkg experts would be helpful.
(In reply to John Hein from comment #4) I've commited newer version of LDB, that depends on openldap-sasl-client. That should resolve this particular issue. But in general the mess with the package dependencies on openldap-client vs. openldap-sasl-client is still waiting for it's hero :(
(In reply to Timur I. Bakeyev from comment #5) samba44 can not be built on head, thanks. Could you merge that commit to the 2017Q1 branch, which is still broken? Thanks.
(In correction to cedric from comment #6) samba44 can NOW be built, sorry.
(In reply to Timur I. Bakeyev from comment #5) Is this really a wise solution? There are many other ports that depend on openldap-client that now will not be possible to install together with the samba44 port for those that install packages from the official pkg repo. Or am I mistaken? Perhaps there instead should be a config option in samba44 that turns on SASL, but which is off by default? I suggest that this is brought up with portmgr for discussion!
(In reply to Bengt Ahlgren from comment #8) Are you aware of any ports that require openldap-client that will not "work" with openldap-sasl-client?
(In reply to John Hein from comment #9) I don't know if there is any port that will not build using the SASL-enabled openldap-client port - I have not checked. But the issue is that most (all?) other packages in the official package repo that need openldap-client depends on the non-SASL port, and will thus not be possible to directly install together with samba44. Examples that I have installed are: $ pkg info -r openldap-client openldap-client-2.4.44: kdepim-4.14.10_3 libreoffice-5.2.3_5 nss-pam-ldapd-0.9.7 kdepimlibs-4.14.10_5 It is not an issue for those building themselves, since then you can set WANT_OPENLDAP_SASL globally for all ports, but for package users, this is an issue. Would it be possible to make the default without SASL, and introduce a slave port (samba44-sasl) with SASL, similar to openldap-client?
(In reply to Bengt Ahlgren from comment #10) By "work", I am including run-time issues as well as build failures. But thanks for the info. I understood the issue you were reporting. I just was looking for more information to guide a solution for it. One solution could be to just get rid of openldap-sasl-client and build openldap-client with sasl enabled always (adds an extra dependency even for those that don't need sasl). Another would be to get the two ldap client library flavors to co-exist (probably harder). Another is what you mentioned: having a SASL option or sasl-flavored slave port for samba (I don't know how much of samba won't work without the SASL-enabled ldap client - maybe Timur can comment on that). p.s. a simple grep shows 80 port Makefiles have USE_OPENLDAP, 20 have WANT_OPENLDAP_SASL.
(In reply to John Hein from comment #11) Note that there already exist ports that have the same problem Bengt is describing (e.g., sysutils/msktutil, security/heimdal, net/ldapscripts to name a few). Some with a hard-coded dependency, some that have the sasl flavor as an option. When you use pkg to install one that requires the sasl flavor (mskutil), pkg will remove openldap-client (and packages that require it) if it is installed before installing openldap-sasl-client. For package users, that's the current state of affairs when faced with installing incompatible package flavors.
(In reply to John Hein from comment #12) It is only sysutils/mskutil (in addition to the samba ports) that defines WANT_OPENLDAP_SASL with default options.
We have version 4.4.16. Is this still relevant?
(In reply to w.schwarzenfeld from comment #14) No, as far as I know it has been resolved.