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 203623 - libijs.so and libgs.so should be in -devel
Summary: libijs.so and libgs.so should be in -devel
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: ghostscript
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks: FC7Target
TreeView+ depends on / blocked
 
Reported: 2006-08-22 19:11 UTC by Patrice Dumas
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 8.15.3-7.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-01-25 12:55:30 UTC


Attachments (Terms of Use)

Description Patrice Dumas 2006-08-22 19:11:38 UTC
Description of problem:

libijs.so and libgs.so should certainly be in -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 Tim Waugh 2006-08-23 08:22:43 UTC
No, since they are dynamically loaded.

Comment 2 Patrice Dumas 2006-08-23 09:55:16 UTC
libgs seems to be linked in gs. Is it dynamically loaded
by another application?

As for libijs.so, it seems not to be directly dlopened by
gs, what is using that library? I see it used in ijsgimpprint
but it is linked against. What does dlopen it?

There is also the opvp stuff I don't completly understand. 
What is dlopened in that case?

Comment 3 Tim Waugh 2006-08-23 10:07:53 UTC
GSview (for example) -- but in general it is intentional that is available for
dynamic loading.

Comment 4 Patrice Dumas 2006-08-23 10:38:16 UTC
Having GSview load libgs dynamically seems wrong to me. 
I really can't see why it doesn't simply link against
gs. It will lead to versioning issues, it seems bad design.

The .so shouldn't be shipped in main packages, only in -devel,
such that linking against gs is only possible with the 
-devel package installed.

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.

If there is a need for a plugin architecture then there should
be a subdirectory below %_libdir for the dlopened plugins, like
what is done in ghostscript:
/usr/lib/ghostscript/8.15
/usr/lib/ghostscript/8.15/X11.so

If there is really a need to dlopen gs, maybe the right thing would
be to add a libgs.so link in /usr/lib/ghostscript/ pointing to 
../libgs.so.8.15

gsview could depend on ghostscript-devel, but I don't
think we should care that much about the gsview issue. gsview
in livna seems to be hacked to dlopen libgs.so.8... And it
is not impossible that gsview tries to dlopen other libs
so -devel will be needed.

Are there other applications that dlopen libgs or libijs?

Comment 5 Patrice Dumas 2006-11-17 15:16:23 UTC
Are there other applications than non-free applications 
that dlopen libgs or libijs? If not I can't see what stop 
them from being in -devel.


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