Packaging question (synopsis and its libraries)
Hi,
I am currently adopting synopsis, a source code documentation
tool specially suited for python, but also useable for
C and C++. I created a first package from the new upstream
version which is available at http://www.littletux.net/debian.
The package is not yet lintian clean, and this leads to my question:
The package contains some python extension modules written in
C/C++, which all depend on a common library, libSynopsis, which is
also part of the package. By default, libSynopsis is installed below
/usr/lib, but without correct SONAME. So I decided to install
it below some private library directory, BUT this included adding
the private library search path to the python extension modules'
RPATH, which I learned is a Bad Thing(TM) (lintian also tells
me about that). I also do not want to fiddle with /etc/ld.so.conf,
so I think the following possibilities exist:
1) Leave it as it is, and add a lintian override. This might
be a proper solution, as it seems that rpaths are not regarded
*that* bad if they point to a "non-public" lib directory, which
would be the case here.
2) Add a proper SONAME to the library and install it
below /usr/lib, from the same binary package.
3) Create separate libsynopsis and libsynopsis-dev packages.
This would have the advantage that the library can be used
by other applications as well (which is also the intention
of the upstream developer, at least in the future). Possible
issue could be that the API is not that stable yet which might
result in many SONAME changes.
4) Some great (and simple :-) ) solution which I dont know yet...
Number 3) is currently my preferred solution, IMHO this would end
up with a package layout similar to
- synopsis The main package. Installing this is sufficient to
use synopsis.
- [optionally: synopsis-doc,
containing information on how to use synopsis itself.
Not yet sure about this.]
- libsynopsis The C++ library.
- libsynopsis-dev The development files
- libsynopsis-doc The API documentation
The upstream author argued that these are too many packages, but
IMHO this is the proper solution if the library is packaged
separatly.
Any comments appreciated :-)
Thanks & Best Regards,
Andreas
--
Andreas Fester
mailto:andreas@littletux.net
WWW: http://www.littletux.net
ICQ: 326674288
Reply to: