Quoting Ghislain Vaillant <ghisv...@gmail.com>:
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":
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.
"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.
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.
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.
The complexity of maintenance you were mentioning was also similar as
in the case of qgis.
What do you think?
Not that it matters anymore, since your source package has now been
sponsored. Good luck with the rest though.
Thanks. I appreciate your feedback and possible interest in
maintaining the package.
Ghis