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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
