[Debian-med-packaging] CamiTK bug fixed(?)

[Andreas Tille]

Hi Emmanuel,

(I just continue in public as you agreed to in your other mail)

On Tue, Jan 08, 2013 at 11:15:02PM +0100, Emmanuel Promayon wrote:
> 
> >There is still something I am not quite happy about:
> >
> >$ cat libcamitk3.lintian-overrides
> ># libcamitk3 distributes two sharedlibs
> ># W: libcamitk3: package-name-doesnt-match-sonames libcamitkcore3.0
> >libqtpropertybrowser3.0
> >libcamitk3 binary: package-name-doesnt-match-sonames
> >
> >However your SOVERSION is 3.0 (and not 3, as per package naming convention):
> >
> >$ readelf -d /usr/lib/libcamitkcore.so.3.0
> >[...]
> >  0x000000000000000e (SONAME)             Library soname: [libcamitkcore.so.3.0]
> >
> >I would like to see a better description in the *.lintian-override so
> >as not to confused people (explain why you think 3 is really the
> >SOVERSION...)
> 
> To be honest, I simply looked and tried to copy what was done in vtk.
> That said, whenever CamiTK changes its API, we so far always
> incremented the major version number, so it seems more logical/clean
> to follow your recomandation.
> 
> I therefore modified the soname properties in the source tarball
> upstream and commented the lintian-override line (should I delete it
> now that it seems to be only filled with comments?).

There is no point in keeping an lintian-overrides file with comments
only.
 
> I now have:
> $ lintian camitk_3.0.3-1_amd64.changes
> W: camitk source: newer-standards-version 3.9.4 (current is 3.9.3)

That's fine.  I guess a

   apt-get install -t experimental lintian

will make this vanish - it can/should be ignored for the moment.

> W: libcamitk3: package-name-doesnt-match-sonames libcamitkcore3
> libmonitoring3 libqtpropertybrowser3
> 
> Although:
> $ readelf -d  libcamitkcore.so.3 | grep SONAME
>  0x000000000000000e (SONAME)             Library soname:
> [libcamitkcore.so.3]
> 
> What do you think?

The warning is not caused because of the different *version* but
rather because of the difference between the package name and
the name(s) of the contained libraries.  The Debian Policy manual[1]
suggests to split up a source package creating different shared
libraries:

  When in doubt, always split shared library packages so that each
  binary package installs a single shared library. 

As far as I know the Debian Library Packaging guide[2] is unmaintained
and outdated / overriden by policy[1] but you might be interested in
this doc as well.  The advises of this library packaging guide are
technically implemented in the d-shlibs package and you can find an
example of using d-shlibs for instance in

   svn://svn.debian.org/debian-med/trunk/packages/libtecla/trunk/

I do not want to say you should solve the lintian warning and split the
shared libraries into different binary packages.  If you have understand
the idea behind this and based on your technical insight into the
software itself are convinced that it is reasonable to keep them all in
one binary package that's fine.  You should explain this in a
lintian-override to explain the issue.

> Note: After the modification upstream, I did not change the name of
> the source tarball on the download page
> (camitk-3.0.3-Source.tar.gz). Hope it is ok during the testing.

I admit I do not fully understand this but considering that we do not
see a 3.0.3 package in the pool I guess it is OK.

> I have another two questions:
> 1) Regarding the distributions of two sharedlibs (in fact now three
> in the new upstream version), do you think it would be a better idea
> to:
> - add four other packages in debian/control, i.e.
> libqtpropertybrowser and libqtpropertybrowser-dev libmonitoring
> libmonitoring-dev

See above.  For instance if you might imagine some separate use of any
of these libraries I'd vote for separate binary packages.  I do not have
detailed insight into camitk so I can not give better advise.

> - add the corresponding inner dependencies (and in this case how to
> formulate it?)

What do you mean by "inner" dependencies?
 
> 2) I moved the source of the specific plugin that was based on
> tetgen out of the camitk source tarball. What would be the best way
> to generate a new package, i.e. libcamitk3-extra-non-free?

If this is something which might bring some extra functionality to our
users which would be missing otherwise this seems to be a reasonable way
to go.  Please remember that in packages in main you can only "Suggests"
packages from non-free (no "Recommends" or "Depends").

> Should I use a separate debian-med project, or is it possible to
> include everything in the current project?

In Git repositories we do have a 1:1 relation between source package and
Git repository (TTBOMK).  In SVN we do sometimes use subdirectories for
strongly related packages.  However, in any case you should have
separate trunk / tags trees for different source packages.  Finally its
a matter of taste and what really matters are the properly specified
Vcs-* fields in debian/control.

> Thanks again for all your time and patience!

No need for thanks.  Educating newcomers finally saves us time in the
long run and without your work we would not manage to get camitk
packaged at all - so you deserves thanks from the community.

Kind regards

      Andreas.

BTW, I CCed you because I do not remember whether you are subscribed to
the Debian Med development list and I think this mail fits better here.
We do often have borderline case and the topic has also content for
users of the package - so finally there is no strict boundary between
those lists.  If you confirm that you are subscribed to both lists I'll
drop the CC because we usually do not CC on our mailing lists.

[1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html 
[2] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

-- 
http://fam-tille.de