On 03/28/2011 16:44, Xin LI wrote:
On 03/28/11 16:30, Doug Barton wrote:
On 03/28/2011 14:20, Xin LI wrote:
On 03/28/11 13:57, Doug Barton wrote:
On 03/28/2011 13:48, Xin LI wrote:
On 03/28/11 12:42, Kevin Oberman wrote:
Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25.
I'll
take a look at CHANGES and see if I can figure out what broke the
inclusion of fetch(3) support if I get a bit of time.
It seems that libldif now referenced the fetch support, and ironically
it seem be a bug but a feature :(
I have decided to disable FETCH support from now on, since it's likely
to bring more problems.
(If you would prefer to fix the problem for this specific problem, I
think adding a '-lfetch' would be sufficient; but, it seems to be
undesirable to depend fetch(3) unconditionally for all programs that
uses openldap).
I know next to nothing about how the openldap-client stuff works, so I'm
sorry if these questions are silly. :) The biggest question is, does
dirmngr compile after your change? The other question is that the only
reason I have openldap installed at all is so that gnupg can use it to
fetch keys from ldap keyservers. Will this still work when the FETCH
option is no longer present?
hmm... how do I test fetching from an ldap keyserver?
I'll save you the trouble. :) I got your latest update and tested both
scenarios myself, and the answer is that they both work.
So now the question is, should the FETCH OPTION be removed altogether? I
imagine that a lot of users will be at least as confused as I, and word
is that PRs for other ports are already showing up.
I think that's being used in some ldap utilities so it might broke some
applications that makes use of that?
I'll add a note in UPDATING to document this.
I think an UPDATING entry is a good idea, however I think that a slave
port would also be useful. Just remove FETCH from the current/master
port, and add a slave with FETCH enabled. That way whatever (few?) ports
that rely on that can change their dependency, and the rest of the users
won't be affected.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
