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

Re: RFS: gwyddion - Scanning Probe Microscopy analysis software



On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote:
> Many thanks for the quick response!
> 
> On 09/07/2007 01:55 PM, Justin Pryzby wrote :
> > On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote:
> >> Furthermore there are lintian warnings, which I did not quieten. They are
> >> about the libgwyddion2 package which contains several libraries and thus
> >> doesn't match the SONAMES of them. What is current practice? Allow the
> <snip>
> > So I think the libraries should only be in the same package if they
> > have the same soname.  (Or, you can put them into a subdirectory of
> > /usr/lib/ if they're not linked against directly and it's no problem).
> The point is, at least as upstream explained to me, that these libraries are
> not particularly well split with regard to their contents. So no one will
> link against just one or some of them. In fact, one often needs some modules
> (which are in the gwyddion package) to build something reasonable. That's
> why I/we (we=upstream+me) decided to put them together.
> Concerning putting them into subdirectories: This would mean creating a
> subdirectory for each library and putting it in there? Could I then keep
> them all in one package?
The directory would be named after the package.
/usr/lib/libgwyddion2/* and either the public libraries or final
binaries would need rpath to find them.  (It still seems a grey area
whether to add a soname and install the lib to /usr/lib or to use
rpath for some things).

> >> And finally there is a duplicate depends of gwyddion on libgwyddion2, one
> >> added by the debhelper scripts and one by me - should I override this, or
> >> take away my hand-written dependency?
> > I think you should drop the manually-added one since the automatic one
> > will always be working with ELF dependency output.
> Should I force a versioned automatic dependency via dh_makeshlibs -V or
> dh_makeshlibs -V 'libgwyddion2 (>=2.8)'?
I think you have to bump the shlibs version whenever upstream adds a
symbol.  Unless you can show (by reading the diff) that a new upstream
*doesn't* do this (or make incompatible changes), it's prolly safe to
increment this at every new upstream.

Otherwise an object compiled against a recent libgwyddion2 with new
symbol would end up in a package with Depends: libgwyddion2 (>=X)
where version X doesn't actually provide the symbol, and an app will
crash whenever the symbol lookup is attempted.

Justin



Reply to: