Bug 203619

Summary: .so should be in -devel
Product: [Fedora] Fedora Reporter: Patrice Dumas <pertusus>
Component: artsAssignee: Than Ngo <than>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-30 11:19:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
support for libdap and fix for hdf none

Description Patrice Dumas 2006-08-22 19:02:49 UTC 
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:
Comment 1 Rex Dieter 2006-08-23 02:06:31 UTC 
Your assumption that all lib*.so should be in -devel is wrong in this case. 
Many of these are runtime-loadable modules.
Comment 2 Patrice Dumas 2006-08-23 08:35:36 UTC 
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?
Comment 3 Rex Dieter 2006-08-23 16:29:50 UTC 
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).
Comment 4 Patrice Dumas 2006-08-23 22:09:18 UTC 
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.
Comment 5 Patrice Dumas 2006-09-14 15:49:53 UTC 
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).
Comment 6 Patrice Dumas 2006-09-14 15:51:39 UTC 
Sorry for the previous comment and patch, it is for another 
unrelated bug...
Comment 7 Than Ngo 2006-10-30 11:19:33 UTC 
it's fixed in arts-1.5.5-0.1.fc6 which is available in FC6 update