Red Hat Bugzilla – Bug 203623
libijs.so and libgs.so should be in -devel
Last modified: 2007-11-30 17:11:41 EST
Description of problem:
libijs.so and libgs.so should certainly be in -devel
Version-Release number of selected component (if applicable):
Steps to Reproduce:
No, since they are dynamically loaded.
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?
GSview (for example) -- but in general it is intentional that is available for
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:
- 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:
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
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?
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.