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

[Andreas Tille]

On Fri, Jan 11, 2013 at 08:55:09AM +0100, Emmanuel Promayon wrote:
> >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.

Please remind the other option to just ignore the standards-version
warning if you mind installing packages from experimental.
 
> 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?

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

Close to correct.  I guess you will get a lintian warning to prefer
(= ${source:Version}) over (= ${binary:Version}) to enable binary
only uploads - but you've got the idea.
 
> >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)

Yes.

> - a specific svn project
> debian-med/trunk/packages/libcamitk3-tetgen-extension that uses the
> separate source tarball and produces a package in non-free

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

That's perfectly fine.  Just add your name to the Wiki and tag your
mails [MoM].  There was some other potentiel MoM student last December
but has not mentioned this until now.  MoM works first comes (on the
Wiki) first served.
 
Kind regards

       Andreas. 

-- 
http://fam-tille.de