[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging question (synopsis and its libraries)

See my recent message to -mentors and -devel, "Nonpublic shared
libraries."  It sees that rpath could be used here because it is a
"private" library, not used by other packages.  In the future, if that
changes, it will have to have a soname.  For now, you could also just
install to /usr/lib/libSynopsis.so, without any trailing version
numbers on the filename.

Clear skies,

On Thu, Sep 29, 2005 at 09:47:00PM +0200, Andreas Fester wrote:
> 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.

Reply to: