Re: [MoM] CamiTK packaging first part
On Thu, Feb 14, 2013 at 09:37:53PM +0100, Emmanuel Promayon wrote:
> Hello,
>
> I just committed some changes on the svn corresponding to the first
> two points of my plan:
> - rtfm (not finished, as I keep finding new things to read or to re-read)
> - update upstream source tarball
> - generate a separate libqtpropertybrowser package from the source tarball
Sounds good so far. I have spotted some lintian info which is not
dramatically but I stumbled the first time about it (you need `lintian -I`)
I: libcamitk3-data: duplicated-compressed-file usr/share/camitk-3.0/testdata/BigEndianCompressed.img.gz
N:
N: The given, apparently compressed, file is shipped in the package in
N: addition to another file with the same name without the
N: compression-method extension. Normally this indicates a mistake in the
N: installation process of the package.
I've checked that it is just a small file but wanted to make you aware
about this.
> All was going well until I reached the point of trying to run the
> camitk-imp application from the generated packages. There was crash
> (and tears).
>
> I then realized that there was some problem with the way application
> plugins (called extensions in CamiTK) are managed that was
> preventing inner-dependencies. An little error from
> dpkg-shlibdeps... I should have known.
>
> It is possible in CamiTK to create an extension that depends on
> other extensions (e.g., a "mixed" extension that manages both a
> medical image using the dicom extension and the mesh of a segmented
> organ using the vtk mesh extension). To do that an extension should
> be able to link against others.
> I had to dig inside the linking process and figure out a way to deal
> with it that can work for every type of build/install.
>
> Therefore, the plugins in 3.0.7 (that are private shared object)
> have now an soname.
>
> I also added some code upstream to be able to quickly diagnose the
> installation state (camitk-imp --config). That should also
> simplify/help bug reports.
Sounds like a really good idea.
> As much as I can test (on one platform, amd64), the produced
> packages are now correct and camitk-imp for example can run without
> a crash (which is a plus!).
>
> I let Andreas review the debian/* files.
> There is something I don't know how to deal with in the d/changelog:
> there is an entry for 3.0.3-1, but this was never uploaded I think.
> Should we remove it?
If you would consider to remove it make sure the actual changes will be
taken over to 3.0.7-1. Alternatively you might like to use UNRELEASED
(instead of unstable) as target distribution. As per Debian Med policy
document you should in principle also do it for the not yet uploaded
3.0.7-1 as well as long as it is not uploaded (you might leave it to
your sponsor to change from UNRELEASED to unstable in the future.)
> Let me know (if everything looks correct, I'll continue on my plan
> for the MoM project),
>From my perspective the package looks fine and I would consider
uploading it.
> PS : the last three days, the sentence from Andreas on the line
> "debian packaging is also good for upstream QA" was in my mind all
> the time!
:-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: