At present, both shared libraries and plugins shipped with samba (3.0.x and 3.2.x) are installed to the location provided to configure with the --with-libdir option. It would be preferable to be able to specify the locations independently. For example, Linux distributions may want to have the shared libraries in a location that can be found by the library loader, but may not necessarily want ldconfig to have to look at plugins. (As an example, OpenLDAP by default puts shared libraries such as libldap in %{_libdir} and other server-specific shared objects such as backends, overlays, and slapi plugins in %{_libdir}/openldap) Additionally, the library symlinks are not created properly (in 3.2.0, on RHEL5 and Mandriva, I actually don't get any symlinks for libnetapi.so, libsmbsharemodes.so, libtalloc.so, libwbclient.so). Currently this means packagers may also have to guess library major numbers (for example, see the Mandriva library policy at http://wiki.mandriva.com/en/Policies/Library, according to which I will be making subpackages such as libnetapi0 etc.). Finally, it is either encouraging, or concerning, that libsmbcient still has a library major number of 0. Either, great care has been taken to maintain binary compatibility (we will ignore the one mistake that has occurred so far), or no attempt is being made to ensure that applications don't get a binary interface they weren't expecting (if the library major number has remained the same while the binary interface has changed). For now I will move the affected shared libraries after 'make install' in the spec file, and assume that the major number for all shared libraries is 0.
Thanks for reporting! I am currently working on getting the library build/install straight in v3-3-test. We'll see if the patches make it into 3.2.x
I have just pushed a bunch of commits to v3-3-test that form a rewrite of the library creation mechanism. Now (in v3-3-test) the library and symlinks are in order, i.e. the shared library created is named as the SONAME and the libfoo.so is a symlink to that. Example: libsmbclient.so.0 is the binary file and libsmbclient.so is a symlink -> libsmbclient.so.0. Further, install and uninstall do properly handle the shared libraries and the symlinks. It would be great if you could verify these bits. I am not sure if this rewrite will make it into 3.2.X because it incorporates quite some changes to Makefile.in and configure.in (but let's try). In any case it will be in 3.3.0 which is expected in 6 months max. Cheers - Michael
Maybe we should split this into two bugs? 1. The separation of libdir into libdir and modulesdir 2. the libraries-link direction and install problems
For the separation of libs and modules dir, I have created a separate bug #5609. Michael
I have merged these fixes to v3-2-stable for inclusion into the next 3.2.x bugfix release.
Patches will be in 3.2.2. Closing out bug report. Please re-open if it is still an issue for you. Thanks for reporting!