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

Re: upgrade orfeotoolbox to 5.0

Hello Bas,

On Sun, Sep 6, 2015 at 1:41 PM, Sebastiaan Couwenberg <sebastic@xs4all.nl> wrote:
On 06-09-15 13:07, Rashad M wrote:
> On Sun, Sep 6, 2015 at 12:20 PM, Sebastiaan Couwenberg wrote:
>> On 06-09-15 09:58, Johan Van de Wauw wrote:
>>> On Sun, Sep 6, 2015 at 1:13 AM, Sebastiaan Couwenberg wrote:
>>>> Splitting the libraries into separate binary packages with symbols will
>>>> get rid of 39 lintian issues.
>>>> Making sure the binary package names match the SONAME will get rid of
>>>> the lintian warning for another three packages:
>>>> [...]
>>> I don't see how this is useful for the OTB users, and it adds a lot of
>>> complexity to the maintenance of the package.
>>> Why would you split this? If one day external applications start using
>>> OTB it may be worth it, but now I don't see the added value.
>> Because the other otb packages can then depend only on the library
>> packages they actually use, as can the library package among themselves.
>> That's why we do this for qgis too, despite upstream not caring about that.
>> Handling shared libraries properly now is better than starting when
>> other packages start to depend on otb. If you don't want to deal with
>> shared library complexity, don't touch packages that contain them.
>> Otherwise handle them properly as documented in the Policy.
> To note that, there is otbice, monteverdi1 and monteverdi2 which uses only
> a part of all otb libs.
> For example, see  this -
> https://git.orfeo-toolbox.org/ice.git/blob/HEAD:/CMakeLists.txt#l64
> only "OTBImageIO OTBVectorDataIO OTBProjection OTBStatistics" libs are
> considered for Ice. It does not need qtwidget or OTBSupervised and many
> others. So it is better for users to atleast to split qt, commandline,
> core.
> Similar is case for monteverdi2 which uses QtWidget but not
> otbApplicationLauncher{CommandLine/Qt}
> Having each into separate libs is what modular architecture of OTB is
> about. Well, that is lot of packages in this case and more work for
> packagers tracking every new module

That's why we use `dh_install --list-missing`, you'll see newly
introduced libraries being built but not installed. That's the trigger
to add new library packages for them.
The extra work to handle more than one shared library in a package is
neglible over just a signle shared library. Updating the symbols is
still the same two commands commands to update the symbols file(s) (one
or more doesn't make a difference).

I will start with group shared libs into seperate packages. For the moment all IO modules could be in a single package.
and IMHO, libotb-dev or libotb should be the package to install everything. Maybe renaming to libotb-all is good in this case.

I will discuss with developers and will get back to you on this by end of this week.

In the mean time, I will update the debian/copyright regarding ITK and push a patch for manpages. Each application has a help option which can be used to generate the man page using help2man.

Because C++ symbols are unstable, that does generate a bit more work,
but easy to automate using pkgkde-symbolshelper. You just need to take
care to update the symbols for other architectures after the buildds
have built the package.

If you don't want to deal with C++ symbols, you'll have to manually
maintain shlibs files. Hence the preference to symbols files that have
tooling for updates.


Including all, except some, libraries in a single package without either
shlibs or symbols will introduce silent breakage because the reverse
dependencies only depend on libotb, a dependency also satisfied with
incompatible libraries bundled in libotb. That's why we had to rename
the library packages for the GCC 5 transitions, the version of the
library may stay the same the symbols it exports did not. This ABI
breakage needs to be reflected in the dependencies on the library package.

I've shared the recommended practices for shared library packages, how
(or not) to incorporate that into the otb package is up to the
maintainer, which I'm not.

Kind Regards,


 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


Reply to: