[Debian-med-packaging] updating camitk package

[Emmanuel Promayon]

>>> What I don't understand is why you added Breaks+Replaces also to
>>> libcamitk4, libcamitk4-data and libcamitk4-doc.
>>
>> I probably added the Breaks+Replace a bit too generously. My initial
>> idea was that someone who had installed the libcamitk3-dev will end up
>> after an upgrade with libcamitk-dev which means and might not need the
>> libcamitk3 anymore (as libcamitk4 will be installed). But I am not sure
>> I understood correctly...
>
> libraries are usually installed as dependencies of other packages, hance
> apt markes them as "automatically installed", they are then removed by a
> `apt-get autoremove`.
> Making 2 different ABI versions of the same library non coinstallable is
> really only an hinderance.

Ok. Thanks for the explanation. I (think I) got it.

>>> Why is camitk-config in the library package at all?  (note that I
>>> don't even know what it does!)
>>
>> camitk-config is a simple application that check the paths and installed
>> plugins. It is required for development but also for diagnostic and test.
>>
>> Thanks again. Let me know if this is correct :
>> - add a new camitk-config package that just have the camitk-config binaries,
>> man pages and icon.
>
> would it make sense to just put it in the -dev package instead?
> I suppose it depends a lot on how much it is correlated to development,
> your choice.

In fact it is necessary for development, but it can also be used as a 
separate diagnostic tool, even for non-developers.

>> - add a Depends:camitk-config to package libcamitk-dev
>> - remove the Breaks+Replace for libcamitk4, libcamitk4-data and
>> libcamitk4-doc
>> - add "Multi-Arch: same" to libcamitk4
>>
>> Does it make sense?
>
> yes.

I have done step 1 and step 2, but I had problem to follow all the 
consequence of step 3 (i.e., make libcamitk4 Multi-arch). The main 
problem occurs with the "dh_install --autodest..." commands, which, from 
what I understood are not compatible with enabling multi-arch.
I decided to drop try to go multi-arch from now, if that is ok.

>> Would that be ok during upgrade to stretch?
>
> well, we don't (usually) upload to stretch :)
> We upload to unstable, then it migrates to stretch after few days.

Sorry, I was not very clear: I did not mean upload directly to stretch. 
My question was on the line "during the upgrade from jessie to stretch, 
do you think that with the current modification the RC bug will be fixed".

Thank you again for your patience,
Emmanuel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20161007/bfafe0fd/attachment.bin>