----- Original Message ----- > From: Jeff Johnson <n3npq@xxxxxxx> > To: John H <uothrawn@xxxxxxxxx> > > On Sep 27, 2011, at 1:18 PM, John H wrote: >> ----- Original Message ----- >>> From: Jeff Johnson <n3npq@xxxxxxx> >>> To: John H <uothrawn@xxxxxxxxx> >> >> How can I get ldconfig to not mess with my files ? >> > > You need to supply a proper soname internal to the library. > > This is (usually) done by passing -Wl,soname,foo to a linkage step somewhere. > > What you seem to be attempting is adding some new symlinks to an > older build of ldap (and so are wrestling with /sbin/ldconfig behavior). > > There's more analysis needed with soname changes, which usually are > undertaken > iff there's a serious incompatibility in the ABI that MUST be avoided. > > I'm unaware of openldap development to "know" why soname changes > were undertaken. CentOS 5.6 uses openldap-2.3. Version 2.3 uses the older (and often broken) slurpd method to replicate LDAP changes across nodes. We are using openldap-2.4 with a simple "make install" on CentOS 5.6 boxes currently. I'm attempting to make an openldap-2.4 RPM as a drop-in replacement for CentOS 5.6 servers. The issue is that openldap-2.3 (mostly the libldap-2.3.so.0 file) is a dependent of many other packages (pam, nss, passwd, etc). This is why I'm trying to get my openldap-2.4 package to "Provide" the 2.3 shared objects--to satisfy that dependency and be a suitable upgrade to openldap-2.3. The openldap-2.3 package has /etc/openldap/ldap.conf (and some other non-consequential manpages) as children files. So if I want to create an openldap-2.4 RPM, its starting to look like the best option would be to just exclude any file which is used by openldap-2.3 from my %files section. This would result in a package something like openldap24-2.4.24 being installed alongside openldap-2.3. The final setup would look something like: openldap-2.3.46 openldap24-2.4.24 (Requires: openldap-2.3.46) openldap24-servers-2.4.24 (Conflicts: openldap-servers) openldap24-clients-2.4.24 (Conflicts: openldap-clients) The openldap24 packages would be missing a few OpenLDAP files to be considered standalone, thereby requiring the openldap-2.3 package. Does this seem like the best solution? Thanks. > But this link > http://linuxtesting.org/upstream-tracker/ > is quite useful for finding the history of changes and incompatibilities. > > SHort answer: > You likely need to build a newer version of ldap, not retrofit symlinks > (but that is just a guess here: I don't have sufficient info to say > anything for sure). > >>> What's likely happening is that running /sbin/ldconfig is removing > the >>> symlinks. >>> >>> And the like (just guessing) reason is that the soname within the > library >>> executable >>> disagrees with the symlinks you are attempting to package. >>> >>> Use readelf -a to display the internal SONAME. >> >> >> readelf -a gives an SONAME of libldap-2.4.so.2 for my libldap-2.3.so.0 > symlink (as expected, given its a symlink). For the openldap-2.3.43 package, the > SONAME is libldap-2.3.so.0. As one would expect... Is this a concern? > LDAP-based login functionality works if I have a symlink even though the SONAME > is wrong. >> > > Hmm if the internal SONAME agrees with the versioning in the symlinks, > then something else is going on. > > You can always *remove* the symlinks from the package, and just let > /sbin/ldconfig > create the symlinks. The only reason to include the sysmlinks in packages is > to attempt to remove if/when a package is removed. These days /sbin/ldconfig > mostly does that (but did not originally). > > > hth > > 73 de Jeff _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
