Description of problem: very strangely some .so are in unixODBC, maybe they should all be in -devel with the other .so and all the .a Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
No, they shouldn't, because those libraries are customarily specified in odbc.ini config files. You don't want to have to change your config file every time the library version changes, do you? (If you do, you certainly can reference the versioned filenames, but I'm not gonna force everyone to do that.)
Couldn't it be possible, instead of shipping the .so in %{_libdir}, to have a special dir for those .so, and the user should be advised to use these? This would avoid being able to link against the libraries while still being able to specify them in config file. They are dlopened when they are in config files, right? So for example there would be a link in %{_libdir}/unixODBC/libodbcpsql.so -> ../libodbcpsql.so.2.0.0 and the link in %{_libdir}, %{_libdir}/libodbcpsql.so -> libodbcpsql.so.2.0.0 would be in -devel. This would also imply changing the /etc/odbcinst.ini such that the %{_libdir}/unixODBC/libodbcpsql.so path is used in the sample, and maybe a README.fedora to document that. Does this seems right?
I'm pretty much failing to see the point. This would still break existing config files, and what does it gain exactly?
If the .so are shipped in %_libdir, it is possible to link against the main package without -devel installed, which is wrong. It is a MUST item here: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. About breaking existing config files, of course it's true so maybe there could be a way to ease the transition, like providing links in new dir and in %_libdir at the same time for some versions.
These libraries are never explicitly linked against, though, so the guideline is irrelevant. Try to get past the filename and recognize that what the guideline is talking about is really a different kind of file. If someone holds a gun to my head and forces me to conform to the letter of the guideline, I will *not* remove the .so files; I'll remove the versioned files instead, because that will break far fewer installations. But I do not think that that guideline applies here.
Do you mean that those libraries are only dlopened, and never linked against, like plugins? In that case, sure they shouldn't be versioned. But also it would be better if they weren't in %_libdir but in a %_libdir subdirectory, %_libdir is for libraries that are linked against, plugins should better be in specific directories.