Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 203641 - all .so should be in -devel
Summary: all .so should be in -devel
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: unixODBC
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: 226515
TreeView+ depends on / blocked
 
Reported: 2006-08-22 20:03 UTC by Patrice Dumas
Modified: 2013-07-03 03:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-22 22:39:40 UTC


Attachments (Terms of Use)

Description Patrice Dumas 2006-08-22 20:03:46 UTC
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 22:39:40 UTC
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 23:29:19 UTC
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-23 02:37:09 UTC
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 08:45:53 UTC
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 14:57:54 UTC
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 15:04:27 UTC
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.