[Pkg-kde-extras] libdigikam.so and #324592

[Achim Bohnet]

Hi,

because we undo the libdigikam -dev split I had a look #324592
again.

In debian policy I found in 10.2
http://www.de.debian.org/doc/debian-policy/ch-files.html#s-libraries

...
Shared object files (often .so files) that are not public libraries,
that is, they are not meant to be linked to by third party executables
(binaries of other packages), should be installed in subdirectories
of the /usr/lib directory. Such files are exempt from the rules that
govern ordinary shared libraries, except that they must not be installed
executable and should be stripped.[53] 

Packages containing shared libraries that may be linked to by other
packages' binaries, but which for some compelling reason can not be
installed in /usr/lib directory, may install the shared library files
in subdirectories of the /usr/lib directory, in which case they should
arrange to add that directory in /etc/ld.so.conf in the package's
post-installation script, and remove it in the package's post-removal
script.
...


libdigikam is not a public library, but on the other hand
digikamimageplugins is not a real 'third party' because they
are developed by the same people and released together when
API changes.

Hole thing is a mess.
For me, the primary question is what is the advantage when we
avoid /usr/lib/libdigikam.so* in pkg digikam?  Or otherwise
is there any disadvantage is keeping /usr/lib/digikam.so

The rules in Library pkg guide and lin* warning are there for a very
good reason.  If one does not follow for a library used in several
independent pkg them one runs in _big_ trouble.  May standpoint
is that libdigikam is not such a library.


Kurt suggested:

...
I see a few options:
- Move them all into the same source package so they don't have
  to build depend on each other.
- Don't install it in /usr/lib so it's clear it's a private lib.
- Make it a static lib only and not a shared one, so API/ABI can
  be changed.  This might not work with all kind of plugins.
...

Last option options seem like the less disattrative one ;)

How should we proceed?  continue arguing?  Implement one
of Kurts suggestion?

Well too late, need sleep.

Achim
-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com