Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
Justin Pryzby schrieb am 07.09.2007 17:46 Uhr:
> On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote:
>> 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).
hmmm, then simply splitting the library package sounds easier... ;-)
>>>> 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.
Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option.
Unfortunately my Linux-installation is screwed up at the moment :-(, but
I'll work on it as soon as I get it fixed (hopefully during the coming
week).
Do you have any comments on this Depends: python | perl | ruby line? Is
it allowed and does it work like one would expect it?
Do you prefer the next package version to be 2.8-2 or should it stay
2.8-1 (there seems to be no real consensus about this)?
Many thanks!
Jan
Reply to: