Hello Bas,
On Sun, Sep 6, 2015 at 1:41 PM, Sebastiaan Couwenberg <[email protected]> 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, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > -- Regards, Rashad
