Red Hat Bugzilla – Bug 203619
.so should be in -devel
Last modified: 2007-11-30 17:11:41 EST
Description of problem: There are .so files in arts they should certainly be in arts-devel. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Your assumption that all lib*.so should be in -devel is wrong in this case. Many of these are runtime-loadable modules.
Indeed, when dlopened .so should be in main package, but in general shouldn't be in %{_libdir}, but in a subdir. Moreover if they are modules that are only runtime they shouldn't have versionning nor sonames. And lastly dlopening should be avoided, although there are indeed valuable uses for plugin systems. If I'm not wrong, the plugin system in arts is handled by mcop. So things should be done such that the .la required by mcop (if I'm not wrong) are in a specific directory, together with .so link if needed. And then the .so of the modules that have an api could be only in -devel. If some application dlopen the arts modules, bypassing mcop, there should be some .so link available, but not in %_libdir, but in %_libdir/arts/ or %_libdir/arts-plugins/ for example, pointing to ../libarts*.so.0.0.* This may be more an upstream issue, but maybe could be worked out at the fedora level. All those .la hanging around in %_libdir with hardcoded stuff, although the dynamic linker can do things right doesn't seems right to me. Anyway are all the libraries plugins? Aren't artsc, *mcop, and maybe other simple libraries that should only be linked?
All good points. IMO, kde should fix a lot of the issues you raise: blurring the difference between shared libs and loadable modules, using non-versioned sonames, and comitting the sin of putting many of them in the same place (%_libdir). Unfortunately, these are all upstream issues, that can't be reasonably addressed here (in Fedora).
It is not such a serious issue in kde as a whole, since all the dirty things are in /usr/lib/kde3, not in %_libdir. At least for kdelibs-devel-3.5.4-2.fc6 kdemultimedia-devel-3.5.4-1.fc6 kdebase-devel-3.5.4-4.fc6 kdepim-devel-3.5.4-1.fc6 But arts puts those in %_libdir.
Created attachment 136273 [details] support for libdap and fix for hdf This fix the hdf4 issue, and add support for dods/libdap. This should work for devel libdap, for previous FC releases `dap-config --client-libs` should not be in LDFLAGS (and shouldn't need to be in LDFLAGS).
Sorry for the previous comment and patch, it is for another unrelated bug...
it's fixed in arts-1.5.5-0.1.fc6 which is available in FC6 update