search

commontk / CTK

A set of common support code for medical imaging, surgical navigation, and related purposes.
https://commontk.org
Apache License 2.0
863 stars 491 forks source link

Add support for debian packages #608

Open jcfr opened 9 years ago

jcfr commented 9 years ago

Currently, the dependencies of CTK are:

At first, I think it would make sense to focus only on CTK libraries (Libs/Core and Libs/Widget) without the other dependencies. That said, I would like to make sure we plan for the other libraries to be available as debian package.

I was thinking about this packages (note that I have no idea about the proper naming convention for Debian packages):

We should also plan for:

@gerddie Based on your experience, what are the current issues ?

Cc: @nolden @pieper

gerddie commented 9 years ago

Thanks for the fast feedback.

At this point my main objective is to get Slicer 4 build in Debian which requires CTK, then I might consider MITK, and from there I would move up to what is possible (if I have the time).

The naming convetion would be 

libctk-*, libctk-*-dev ...

I'm not so sure whether at this point it is really split package into many sub-packages, it depends on what will usually required by third party software that makes use of CTK. My approach would be to create packages libctk-all, python-ctk-all, an libctk-all-dev, and maybe ctk-tools if there actual applications that are not just development helpers.

At first these packages would include everything that is actually build, and then I would start to move parts into smaller packages and let the all- packages depend on these. This would also be in line with my preferred approach to go one step at a time and enable more things as they are required, added, enabled ...

One thing that is crucial is to disable SuperBuild and only rely on packaged 3rd party libraries. (For instance I have seen that PythonQT is a bit a mixed bag in that it says using the system version is not possible, but then again for QT5 one has to provide an installed version.)

My experience with CTK so far is two days old an so far it looks quite good based on what I want to achieve, i.e. the package builds with the small two patches that I sent with #609 added.

Regarding the Installation, I just noted that you move all library files into a ctk-.X.X subdirectory of /usr/lib/. While this good for the plugins, CMake and designer modules, the normal shared libraries should better go into /usr/lib/. - Actually , instead of using /usr/lib/ it is better to use /usr/lib/ as a base directory for the libraries (cf. cmake: GNUInstallDirs).

Best, Gert

jcfr commented 9 years ago

my main objective is to get Slicer 4 build in Debian which requires CTK

:+1:

At first these packages would include everything that is actually build

Make sense

crucial is to disable SuperBuild and only rely on packaged 3rd party libraries

  • Slicer build system support option like -DSlicer_USE_SYSTEM_<external>:BOOL=ON where <external> is any name available as SuperBuild/External_<external>.cmake. For example, see r22724. CTK works the same.
  • It means we will have to contribute fixes upstream. For PythonQt, DCMTK and teem we are in touch the project maintainers and this should not an issue. Assuming, the generation associated debian package follow ... things should work out. Regarding, ITK, VTK and CTK ... same idea.

you move all library files into a ctk-.X.X subdirectory

All the install locations are now configurable. For example, see here for CTK.

We also created a migration plan to re-organize files within Slicer build and install tree, see Documentation/Labs/FHSCompliantDirectoryStructure, your feedback would be greatly appreciated.

gerddie commented 9 years ago

Slicer build system support option like -DSlicer_USESYSTEM:BOOL=ON where is any name available as SuperBuild/External_.cmake. For example, see r22724. CTK works the same.

Yes, I found the SUPERBUILD=OFF switch in CTK and IIRC also in Slicer :)

Regarding upstream versions of the required packages, usually the latest version will go into Debian, so if upstream integrates your changes and prepares a release then these should eventually find their way into the archives.

What would then be nice though is that if you prepare a CTK, and a Slicer release that these can depend on these released upstream versions, and that these versions are documented in the release notes. I understand that Slicer is a very fast moving project and I hope that this can be made possible for the next release. Otherwise I'd probably opt for packaging an older version first, to get everything in place, and then update when possible.

Considering the install tree:

gerddie commented 8 years ago

HI, I just wanted to send a ping to see if there has been any progress, especially with the integration of changes into upstream packages?

jcfr commented 8 years ago

Hi @gerddie

Thanks for the reminder.

As of today, we are working on having all Slicer specific changes upstream to VTK, same idea for ITK changes. Once this is complete we will be closer to the goal.

In the mean time, your help would be appreciated to identify what is missing for the other packages.

Do you also have any pointer that would us identify what are the prerequisites to successfully have a package built for Debian.

Thanks Jc

Cc: @msmolens @thewtex @mathstuf

thewtex commented 8 years ago

Since both Debian and Slicer do an outstanding job keeping and up-to-date ITK, there should few issues there.

gerddie commented 8 years ago

I'm not quite sure what you mean by "missing for the other packages" apart from what I pointed out above, i.e. that all local changes you do to 3rd party software should be integrated into upstream, and that it would be helpful to document the version dependencies. Then, when your changes to vtk, itk and PythonQT (for QT5) are a available from release versions, it would be a good moment to tag a (pre-)release version for CTK (I don't like packaging based on git commits) - which would be my signal to update the experimental CTK package in Debian and then move on to package Slicer.

nolden commented 6 years ago

@jcfr @tillea recently worked on issue #839 which is great. Maybe we could get some momentum again on the packaging topic. I remember a wiki page we should probably update, and I'm very happy to help:

http://www.commontk.org/index.php?title=Debian_Packaging

tillea commented 6 years ago

Hi, On Mon, Oct 29, 2018 at 12:53:25AM -0700, Marco Nolden wrote:

@jcfr @tillea recently worked on issue #839 which is great. Maybe we could get some momentum again on the packaging topic. I remember a wiki page we should probably update, and I'm very happy to help:

http://www.commontk.org/index.php?title=Debian_Packaging I'm really happy about your enthusiasm but I have some unfortunate news for you. The packaging for ctk was removed from Debian some time ago: https://tracker.debian.org/pkg/ctk The reason is that the expert in this field left the packaging team and I simply stumbled upon this to update some general packaging metadata. Sorry to say that you can not really trust on my to do the packaging work myself. However, I'd gladly help to re-inspect the old packaging code and to teach you in a mentoring project. This has turned out successfully in several cases in the past and I'd happily do so. Kind regards, Andreas.