Description of problem: Unversioned *.so files are part of main unixODBC package, but they should be part of unixODBC-devel package Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. dnf install unixODBC -y 2. cd /usr/lib64 3. ls -l libodbc* Actual results: output contains unversioned *.so files, even if unixODBC-devel is not installed Expected results: No unversioned *.so files as a part of the output Additional info:
Fixed in PR: https://src.fedoraproject.org/rpms/unixODBC/pull-request/5
It's been a long time, but I seem to recall that this is an intentional and essential packaging choice, because client applications pull in ODBC libraries via dlopen not by normal linking. If you move the .so's then clients will fail at runtime unless they install the -devel package, which is surely not what we want. If this is correct it'd likely be a good idea to document it in the specfile, as I evidently failed to do.
Thanks for info, do you consider dlopening versioned *.so files as problematic ?
(In reply to Ondrej Dubaj from comment #3) > Thanks for info, do you consider dlopening versioned *.so files as > problematic ? It's extremely problematic. Removing the setup libraries (the *S.so ones) would break user-written configuration files; as an example of expected usage see the examples in README.dist. I am less sure offhand what the scenario for dlopen'ing the other files is. I notice in the revision history that I explicitly moved libodbcinst.so from the devel to main package (cf 62398503b6943856bc8714852c9b0ce01368609c). I no longer have access to bug #204882 to see the exact user complaint, but you can be certain that this proposal is reverting a bug fix. The other ones that are in the main package are before my time. It looks like Fernando moved some of them on Oct 10 2003, and Trond's entry on Mar 26 2002 sounds related too, but git's history goeth not that far back. Anyway, it certainly looks to me like this proposal is breaking deliberate long-ago decisions for no reason other than slavish adherence to a packaging rule. I suspect you'll just end up reverting it once the users see it.
Studying the changelog some more, it looks like bug #72653 is also relevant. That one I can see, and it's complaining that ODBCConfig and OpenOffice don't play nice with unixODBC without the symlinks present.
Sorry for the late response, it is one thing, that the update might break some packages, but it is a right thing to do. The bugs you linked are related to old RHEL problems and the fixes were backported to fedora as well. I do not see it as a big problem to rebuild the dependend packages with additional dependency on unixODBC-devel package, if it will be needed. Or if there will be some runtime problem, it can be easily fixed by editing the config file and dlopening the versioned libraries. If there will be a big need not to edit the config files, there is nothing simpler than installing unixODBC-devel package and everything works again.
[ shrug... ] The experience of three unixODBC maintainers before you is that users will complain (legitimately IMO) if they're forced to install unixODBC-devel in order to use the base package. If you refuse to learn from the past, I can't stop you from learning this lesson the hard way.
The resulted changes look like: Moving unversioned libraries from unixODBC main package to unixODBC-devel package. Also moving unversioned plugins, which are in main package from %{_libdir} to %{_libdir}/unixODBC according to fedora packaging standards [1] So the resolution will look like Main package: %{_libdir}/libodbccr.so.2 %{_libdir}/libodbccr.so.2.0.0 %{_libdir}/libodbcdrvcfg1S.so.2 %{_libdir}/libodbcdrvcfg1S.so.2.0.0 %{_libdir}/libodbcdrvcfg2S.so.2 %{_libdir}/libodbcdrvcfg2S.so.2.0.0 %{_libdir}/libodbcinst.so.2 %{_libdir}/libodbcinst.so.2.0.0 %{_libdir}/libodbcminiS.so.2 %{_libdir}/libodbcminiS.so.2.0.0 %{_libdir}/libodbcmyS.so.2 %{_libdir}/libodbcmyS.so.2.0.0 %{_libdir}/libodbcnnS.so.2 %{_libdir}/libodbcnnS.so.2.0.0 %{_libdir}/libodbcpsqlS.so.2 %{_libdir}/libodbcpsqlS.so.2.0.0 %{_libdir}/libodbc.so.2 %{_libdir}/libodbc.so.2.0.0 %{_libdir}/libodbctxtS.so.2 %{_libdir}/libodbctxtS.so.2.0.0 %{_libdir}/unixODBC/libodbcmyS.so %{_libdir}/unixODBC/libodbcpsqlS.so %{_libdir}/unixODBC/libtdsS.so + rest of the provided files, which won't be changed Devel-package: %{_libdir}/libodbccr.so %{_libdir}/libodbcinst.so %{_libdir}/libodbc.so %{_libdir}/libodbcdrvcfg1S.so %{_libdir}/libodbcdrvcfg2S.so %{_libdir}/libodbcminiS.so %{_libdir}/libodbcnnS.so %{_libdir}//libodbctxtS.so + rest of the provided files, which won't be changed [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages