Re: Any software package for Radiation Oncology Contouring?
Hello Adit,
thank you very much for your interest in Debian Med. For our project it
would be a really great addition to also support radiation therapy
research - so I really hope to get it packaged for Debian soonish. I'm
personally neither involved nor educated in this field and I hope that
our experts here on this list will rise their hand and volunteer for
packaging. If this might not be the case I'll probably try to step in
and do the packaging work. However, the testing of the resulting
packages needs to be done by somebody who has a real use for the
packages.
So far for the general position - read below for certain details:
On Mon, Mar 14, 2011 at 07:12:51PM -0500, Adit Panchal wrote:
> I am the lead developer of dicompyler. I thought since the topic came
> up here on debian-med, we could work together to try to get dicompyler
> ready for packaging. In a few months we will be releasing version 0.4,
> so before that happens, we can try to make the changes necessary on
> our end.
>
> Our build requirements page is here:
> http://code.google.com/p/dicompyler/wiki/BuildRequirements
I've checked the requirements and as far as I can see all preconditions
are available in Debian. :-)
Regarding "Getting the source": While it is perfectly possible to
obtain the source from any Version Control System it would be of great
help if you would release your final code into versioned tarballs.
So even if we are targetting at your not yet released version 0.4
it would be good to know that you have released something like
dicompyler-0.3.tar.gz at your download page[1] (and perhaps previous
versions) and that we can trust to find dicompyler-0.4.tar.gz on
this (or some other defined) location.
The rationale behind this is that we always need to provide a source
tarball in Debian and that it is the easiest way to use the "official"
upstream tarball. We also have an automatic system which verifies the
upstream site every day for new updates - it would be a shame if we
would not have this option.
> Also, one of our users has committed some changesets to a clone which
> prepares the project for distutils. It is not on the mainline code
> yet, but may be useful as a starting point:
> http://code.google.com/r/nielsbassler-dicompyler/source/list
Could you please clarify what in this connection "clone" would mean
(Niels Bassler is in CC)? Will this code be merged at some point in
time? What should be our code we should target for Debian inclusion?
If it is just the distutils build system I do not think it is the best
idea to have two clones hanging around in different Version Control
Trees. It is confusing for visitors of these pages and finally more
work for you to set up different pages with same information. I also do
not understand the relation of nielsbassler-dicompyler and PyTRiP (which
is mentioned on the later page).
Is PyTRiP a different project (solving different tasks) than dicompyler
or it is rather a competing project targeting at the same workflow but
with different code. I did not found a license at the PyTRiP
homepage[2] even if there is some link to the source code in TRAC.
> Let me know any suggestions to get started.
So we need to clarify first:
1. What will be the target project for Debian inclusion
Dicompyler or nielsbassler-dicompyler (in case it is not
intended to merge both projects again).
2. If this is decided can you please release source tarballs
of this project. If the difference in the build system
between a previous release and the future release is not
very large we might start the packaging even with an older
version and just upgrade your upstream code for a final
release. If the build system is quite different we might
consider a dicompyler-0.3.99alpha.tar.gz (or whatever version
to start working on this).
3. If you personally feel able to take over some packaging
work under the guidance of the Debian Med team this could
turn out as a quite fruitful cooperation. It worked quite
good in the past. Debian packaging is not that hard to
learn in the end and we will patiently help you doing so.
Kind regards
Andreas.
[1] http://code.google.com/p/dicompyler/downloads/list
[2] http://aptg-trac.phys.au.dk/pytrip/
--
http://fam-tille.de
Reply to: