Bug 203641 - all .so should be in -devel
all .so should be in -devel
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: unixODBC (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
:
Depends On:
Blocks: 226515
  Show dependency treegraph
 
Reported: 2006-08-22 16:03 EDT by Patrice Dumas
Modified: 2013-07-02 23:10 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-22 18:39:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2006-08-22 16:03:46 EDT
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:
Comment 1 Tom Lane 2006-08-22 18:39:40 EDT
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.)
Comment 2 Patrice Dumas 2006-08-22 19:29:19 EDT
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?
Comment 3 Tom Lane 2006-08-22 22:37:09 EDT
I'm pretty much failing to see the point.  This would still break existing config files, and what does it gain 
exactly?
Comment 4 Patrice Dumas 2006-08-23 04:45:53 EDT
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.
Comment 5 Tom Lane 2006-08-23 10:57:54 EDT
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.
Comment 6 Patrice Dumas 2006-08-23 11:04:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.