On 28-09-15 21:57, Rashad M wrote:
> On Mon, Sep 28, 2015 at 9:24 PM, Sebastiaan Couwenberg wrote:
>> On 28-09-15 21:04, Rashad M wrote:
>>> On Mon, Sep 28, 2015 at 10:18 AM, Bas Couwenberg wrote:
>>>> On 2015-09-28 10:13, Bas Couwenberg wrote:
>>>>> On 2015-09-28 09:51, Rashad M wrote:
>>> Q: currently I haven't done moving shared library into separate package.
>>> I hope to do that after getting the packages into experimental. Is that
>>> okay?.
>>
>> That's not smart, because the new binary packages will have to pass the
>> NEW queue again. Having two subsequent uploads pass the NEW queue is not
>> a wise use of time.
>>
>>> Splitting files into separate .install is easy but I need to build
>>> the dependencies in the control file. This seems not trivial... unless I
>>> am missing something.
>>
>> dh_makeshlibs and ${shlibs:Depends} in control take care of that. If you
>> use to the tooling for its intended purpose you don't need to set manual
>> dependencies on shared libraries.
>>
>
> I am not clear about this. If libotbX depends on libotbY, libotbZ then I
> need to mention them precisely in the control file. This is the case of
> otb-bin and otb-bin-qt now.
You only needed the manual dependencies because you weren't using
symbols nor shlibs files.
With symbols files dh_shlibdeps can determine which library package for
libotbY & libotbZ and versions thereof is required for the symbols used
by libotbX.
With shlibs files it's not possible to determine the version based on
the symbols used, instead the dependency specified in the shlibs files
for libotbY & libotbZ is used for ${shlibs:Depends} of libotbX.
> Does shlibs:Depends takes care of the correct dependencies and not more. I
> mean only those required by libotbX.
The ${shlibs:Depends} substitution variable is populated by
dh_shlibsdeps with all the shared library dependencies used by libotbX
using the symbols or shlibs files for libotbY & libotbZ.
In one of my earlier messages in this thread (that is getting to damn
deep!</meme>) I mentioned that the hardcoded dependency on libgdal1h
should be removed because ${shlibs:Depends} already takes care of that.
If libotbX uses any C++ symbols exported by libgdal it will get a
dependency on libgdal1i because this is configured in the first line of
the symbols file:
libgdal.so.1 libgdal1i #MINVER#
Any package that lists libgdal.so.1 in its NEEDED section will get a
dependency on libgdal1i because that is the package that provides
libgdal.so.1. (You can also use #PACKAGE# in the symbols file to have it
determine the package name based on the filename).
GDAL is special because its C++ symbols are unstable, causing frequent
breakage due to missing symbols, we have therefore enhanced the symbols
file to use an alternative dependency template for the C++ symbols.
Whenever a package uses any of the GDAL C++ symbols it will use the
dependency as configured in the second line of the symbols file:
| libgdal1i #MINVER#, libgdal.so.1-1.11.3
For C symbols you only get "libgdal1i (>= <VERSION>)" in ${shlibs:Depends}.
For C++ symbols you get "libgdal1i (>= <VERSION>), libgdal.so.1-1.11.3"
in ${shlibs:Depends}.
#MINVER# is set to the highest version of the symbols used.
You can interpret the first line of a symbols file like this:
"If your need the libgdal.so.1 library, you need to depend on the
libgdal1i package greater than or equal to version #MINVER#."
shlibs files do something similar, except that the version requirement
is not determined automatically based on the used symbols but is
specified by the package maintainer.
For GDAL we could use a shlibs file like this:
libgdal 1 libgdal1i (>= 1.11.3)
And update the minimum required version manually every time, but the
symbols file automate the version requirement making that a better choice.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1