Unable to configure dirmngr after openldap upgrade
dougb at FreeBSD.org
Mon Mar 28 23:47:27 UTC 2011
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.
>>>>>> 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.
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/
More information about the freebsd-ports