Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC)

Quoting Michael Bushkov <bushman_at_rsu.ru> (from Tue, 22 Aug 2006  
20:26:18 +0400):

> Dag-Erling Smørgrav wrote:
>
>> "Michael Bushkov" <bushman_at_rsu.ru> writes:
>>
>>> Li Xin wrote:
>>>
>>>> Would you please consider having the imported OpenLDAP to install
>>>> shared objects under alternative names? It might be painful for
>>>> users who wants OpenLDAP installation from the ports collection
>>>> (as OpenLDAP team moves fast and fixes bug from time to time) if
>>>> they get a same library in /usr/lib...
>>>>
>>> I've been thinking about that. Would names like "libldap_i.so" and
>>> "liblber_i.so" be ok ("_i" means "imported", or "internal")?
>>>
>>
>> Please don't.  If somebody isn't happy with the base system's libldap,
>> they can add WITHOUT_LDAP to their make.conf.
>>
>> DES
>>
> This issue turned to be more complex than I originally expected. I
> believe that "not having 2 different entities in the system, that do
> the same thing" is the good rule. So maybe, leaving libldap.so(a) in
> /usr/lib is not an absolutely good decision. But renaming libldap to
> some other name and leaving it there (and enforcing everything beside
> the base system to use almost the same ports' libldap) is probably much
> more worse.
> So, after all, I'd prefer to leave libldap (and nss_ldap, which can
> also conflict with PADL's nss_ldap) as is and let users use
> WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate.

If someone doesn't like the base system libldap, but wants the  
nss_ldap stuff, this way will not work out. While building the base  
system, no 3rd party libs are known to the build infrastructure.

Conflicting libs aren't good and some people may want to have more  
recent versions of a lib installed. To solve this issue phk didn't  
importet "libxml", but renamed it to "libbsdxml" (we only need to  
update the lib if we need a new feature, or if there's a security  
problem). This way base system tools are able to use a XML lib while  
ports can use a more recent version of it (ports aren't using our  
version of the lib).

So this is not like the openssl or kerberos cases from the  
lib-handling point of view (I'm talking about the ports<->basesystem  
interaction, not about updating the lib in the basesystem).

An idea which wasn't suggested yet is to install a renamed version (I  
would suggest libbaseldap instead of libbsdldap or libldap_i, but I  
don't really care about the name) and a link from the original name  
(only the .so and .a, but not the .so.X) to the new name. This link  
can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way  
around... depending on what we want to achieve). This way it is  
possible to link with the renamed lib in the base system, to use the  
base system version of the lib in ports, and to use the lib from ports  
if desired (a recompile of ports may be needed in the last case, yes).

Bye,
Alexander.

-- 
The gent who wakes up and finds himself a success hasn't been asleep.

http://www.Leidinger.net    Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild _at_ FreeBSD.org  : PGP ID = 72077137