Unable to configure dirmngr after openldap upgrade

[Doug Barton]

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/