Date: Wed, 23 Aug 2006 12:11:57 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Michael Bushkov <bushman@rsu.ru> Cc: Dag-Erling =?utf-8?b?U23DuHJncmF2?= <des@des.no>, freebsd-current@freebsd.org, LI Xin <delphij@delphij.net> Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) Message-ID: <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> In-Reply-To: <44EB302A.7010106@rsu.ru> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Michael Bushkov <bushman@rsu.ru> (from Tue, 22 Aug 2006 =20
20:26:18 +0400):
> Dag-Erling Sm=C3=B8rgrav wrote:
>
>> "Michael Bushkov" <bushman@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 =20
nss_ldap stuff, this way will not work out. While building the base =20
system, no 3rd party libs are known to the build infrastructure.
Conflicting libs aren't good and some people may want to have more =20
recent versions of a lib installed. To solve this issue phk didn't =20
importet "libxml", but renamed it to "libbsdxml" (we only need to =20
update the lib if we need a new feature, or if there's a security =20
problem). This way base system tools are able to use a XML lib while =20
ports can use a more recent version of it (ports aren't using our =20
version of the lib).
So this is not like the openssl or kerberos cases from the =20
lib-handling point of view (I'm talking about the ports<->basesystem =20
interaction, not about updating the lib in the basesystem).
An idea which wasn't suggested yet is to install a renamed version (I =20
would suggest libbaseldap instead of libbsdldap or libldap_i, but I =20
don't really care about the name) and a link from the original name =20
(only the .so and .a, but not the .so.X) to the new name. This link =20
can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way =20
around... depending on what we want to achieve). This way it is =20
possible to link with the renamed lib in the base system, to use the =20
base system version of the lib in ports, and to use the lib from ports =20
if desired (a recompile of ports may be needed in the last case, yes).
Bye,
Alexander.
--=20
The gent who wakes up and finds himself a success hasn't been asleep.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060823121157.yawh6f8e844w4osc>