On Mon, Sep 28, 2015 at 10:37 PM, Sebastiaan Couwenberg <[email protected]>
wrote:
> 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.
>
Thanks Bas for detailed explanation. As the current way of packaging is
different from earlier(ubuntugis etc..) for me, it created confusion.
I had the following TODO on my side before getting into experimental queue:
split packages
add symbol files with pkgkde-symbolshelper
fix any remaining lintian issues.
I will keep you updated.
> Kind Regards,
>
> Bas
>
> --
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
>
>
--
Regards,
Rashad
