On Sun, Sep 6, 2015 at 12:20 PM, Sebastiaan Couwenberg <[email protected]> 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: > >> > >> W: otb-bin-qt: package-name-doesnt-match-sonames libOTBQtWidget-5.0-1 > >> W: otb-bin: package-name-doesnt-match-sonames libOTBCommandLine-5.0-1 > >> libOTBCommandLineParser-5.0-1 > >> W: libotb: package-name-doesnt-match-sonames > >> libOTBApplicationEngine-5.0-1 libOTBCarto-5.0-1 libOTBCommon-5.0-1 > >> libOTBCurlAdapters-5.0-1 libOTBEdge-5.0-1 libOTBExtendedFilename-5.0-1 > >> libOTBFuzzy-5.0-1 libOTBGdalAdapters-5.0-1 libOTBIOBSQ-5.0-1 > >> libOTBIOGDAL-5.0-1 libOTBIOKML-5.0-1 libOTBIOLUM-5.0-1 > >> libOTBIOMSTAR-5.0-1 libOTBIOMW-5.0-1 libOTBIOONERA-5.0-1 > >> libOTBIORAD-5.0-1 libOTBIOTileMap-5.0-1 libOTBImageBase-5.0-1 > >> libOTBImageIO-5.0-1 libOTBImageManipulation-5.0-1 libOTBMathParser-5.0-1 > >> libOTBMetadata-5.0-1 libOTBOSSIMAdapters-5.0-1 > >> libOTBOpenThreadsAdapters-5.0-1 libOTBPolarimetry-5.0-1 > >> libOTBProjection-5.0-1 libOTBRCC8-5.0-1 libOTBStreaming-5.0-1 > >> libOTBSupervised-5.0-1 libOTBTestKernel-5.0-1 libOTBTransform-5.0-1 > >> libOTBVectorDataBase-5.0-1 libOTBVectorDataIO-5.0-1 libOTBWavelet-5.0-1 > >> libotbossimplugins-5.0-1 libotbsiftfast-5.0-1 > > > > 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 > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > -- Regards, Rashad
