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

[Emmanuel Promayon]

On 11/01/13 13:15, Andreas Tille wrote:
> 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.

Ok.

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

Great. I will do that then.

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

Ok. I will check the syntax as well.

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

Perfect. I will do that then.


>> 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.
I am still a little busy till the end of January. Can I apply for february?

Kind regards,
Mahnu