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,
Justin
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: