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).
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,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1