Quoting Ghislain Vaillant <ghisvail@gmail.com>:
I didn't mean RTFM (Read the fine manual). When I was having initial package review, I was asked to move shared libs into separate packages. I initially had separated qt and python stuff only.On 29/12/15 10:09, Rashad Kanavath wrote:Hi Ghislain, debian policy for shared library says each library must be in a seperate package [1].The following citation from the very link you provided is far from the definition I know of "must":
"If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together."OTB is well modularaized since 5.0.0. This allows external apps or libaries to use have some of the otb libs not all For instance, monteverdi required only a small subset of libs: OTBApplicationEngine OTBQtWidget OTBImageIO OTBVectorDataIO OTBTestKernel OTBCarto OTBProjection OTBStatistics So splitting a shared library is useful there. It also aslo true for remote modules. If anyone want to write a remote module that depends on two other modules OTBCommon, OTBTestKernel. he don't need to drag in all dependencies for that.The modularization of OTB follows pretty much what ITK does from the distant look I had of it, and I am familiar with how VTK / ITK is packaged in Debian. Still neither of both were modularized too much besides the separation of the Python and Qt specific stuff, in order to reduce (co)maintenance burden. Again, you're the maintainer and the final decision is totally yours here.
yes. modularization of otb follows that of itk.
Besides, all the modules you provide seem to qualify for the case I cited above (same goes for ITK / VTK), hence my suggestion to place them in a common shlib package. Since you assumed that the policy "forced" you to do otherwise, I understand why you considered my advice defensively.
Not exactly. If there is some issue with the current state of packaging, I am okay to fix it.
ofcourse, going back to single libs is easy but a lot of work will be wasted.But I don't have a problem with that. sorry If I sounded defensive to your comments, it may be because i was doing a single shared libs at first and then I decided to split them.
I guess maintaining the symbols file is easier when packages are separated. And before I start, I looked into other packaging works in DebianGIS. All of them follow this way. So I stick to that.And in future otb may have more modules. If there is a problem with split up libraries, I can change it and make it simply libotb and libotb-devI can't comment on the "simplicity" of the conversion. Perhaps you have more experience on this aspect of packaging than I do.On a side note, by contributing to other packages than I personally maintain, I can tell you one thing: the more complicated the packaging, the least I have been inclined to invest time in co-maintenance. That is likely to apply to others.
The complexity of maintenance you were mentioning was also similar as in the case of qgis.
Thanks. I appreciate your feedback and possible interest in maintaining the package.What do you think?Not that it matters anymore, since your source package has now been sponsored. Good luck with the rest though.
Ghis