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

[Emmanuel Promayon]

Hi Andreas,

> (I just continue in public as you agreed to in your other mail)
thank you. I am subscribed to the debian-med-packaging list (and will 
not hesitate to use the mailing list from now on).
However, I just realized that I had not subscribed to debian-med list 
(this is done now)!

> There is no point in keeping an lintian-overrides file with comments
> only.
Ok.
However, considering your answer their might still be some need for it 
in the end!

> That's fine.  I guess a
> apt-get install -t experimental lintian
> will make this vanish - it can/should be ignored for the moment.
Ok.
The workstation I use to compile the package is running ubuntu (I use 
pbuilder create --distribution sid to test the packagaing). I will look 
into the solution to use the "-t experimental" flag with it.

Regarding:
>> 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.

and:
>> 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.


There is in fact two cases:
1) libqtpropertybrowser: it is based on Qt. It comes from the Qt 
Solutions that were recently distributed under BSD, see 
http://qt.gitorious.org/qt-solutions/qt-solutions/trees/master/qtpropertybrowser.
It offers a easy way to generate a GUI for Qt Property, and that is why 
it was included in the CamiTK sources.
It is not yet packaged for debian. It is also very generic (can be used 
with any library based on Qt), and does not have a specific 
medical/life-science objective.

It seems the best thing to generate two .deb packages directly from 
camitk source (until someone is willing to do a specific/separate 
packaging).


2) libmonitoring is in fact strongly linked with CamiTK (and even if it 
could be used without/outside CamiTK, it is much more useful/powerful to 
use it inside camitk).
So in this case, I suppose it can go to libcamitk-dev.

Does that sound ok?

I have other questions about what is the best policy for packaging, but 
I will separate them in another thread, to avoid "pollution" in this 
already long message!

>> - add the corresponding inner dependencies (and in this case how
>> to formulate it?)
>
> What do you mean by "inner" dependencies?

I mean the dependencies specified inside the debian/control file (inner 
because libcamitk3 will depends on libqtpropertybrowser build from the 
same source tarball).

Does something like:
Package: libcamitk3
Architecture: any
Depends: libqtpropertybrowser (= ${binary:Version}), ${misc:Depends}, 
${shlibs:Depends}
...
sounds correct?

>> 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").

Ok. It is better to make sure libcamitk stays in main, you are right.

>> 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.

So if I understand correctly, their should be:
- a separate source tarball for this plugin (upstream)
- a specific svn project 
debian-med/trunk/packages/libcamitk3-tetgen-extension that uses the 
separate source tarball and produces a package in non-free

>> 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.

It might be a good idea for me to enter your MoM, what do you think?

Kind regards,
Mahnu

[1] http://debian-med.alioth.debian.org/docs/policy.html#introduction