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.
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.
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-dev
I 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.
What do you think?
Not that it matters anymore, since your source package has now been sponsored. Good luck with the rest though.
Ghis