On 19/08/07, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote: > Michael Schwendt writes: > > > On 19/08/07, Andy Green <andy@xxxxxxxxxxx> wrote: > >> Somebody in the thread at some point said: > >> > >> > ./libmylib.so.1 ln -s /usr/lib/libmylib.so.1 libmylib.so The > >> > requirement is /usr/lib directory will have : libmylib.so.x > >> > libmylib.so -> libmylib.so.x > >> > >> Throw out your ln command altogether. Just place the .so in /usr/lib > >> and run /sbin/ldconfig in %post. It will make the symlinks according to > >> the library soname. > > > > That is false advise, however, since you want to create all necessary > > symlinks in the %install section in order to include them in the > > %files section and the package. If you don't include the symlinks in > > the package, but let ldconfig create them, the files don't belong to > > any package, which is a packaging bug. > > Really? Yes. > Maybe you should then file this bug against a few hundred or so Fedora > packages, that have been doing this for years. No, they don't do that. > $ rpm -q -a --scripts | grep 'install program' | grep ldconfig | wc -l > 571 That is only one part of library packaging. You here query the scripts, not the files that are included in the package. The primary purpose of running /sbin/ldconfig in the post-install and post-uninstall scripts is to update the run-time linker's cache, not to create any symlinks. When the symlinks are included in the package already, querying the files with "rpm -qf" works as it should, and ldconfig does not recreate any of the symlinks unless there is a local install of a matching library name with a higher minor version. Not including the shared library symlinks in the %files list is a packaging bug. Not running ldconfig is another one. [Btw, it is quite a common mistake among users to suggest running ldconfig in order to fix a failed compilation attempt. ldconfig does not create any libfoo.so links, but just the versioned libfoo.so.X.Y <- libfoo.so.X links.]
