Re: InVesalius packaging (Was: Open source 3D medical imaging software using wxPython)
Dear Tatiana,
On Thu, Feb 25, 2010 at 03:29:07PM -0300, Tatiana Al-Chueyr wrote:
>
> That is great! Thanks! I've already checked it out, but I have some
> remarks and doubts.
At first: Please do not take my work as kind of law - while I have some
experience in Debian packaging if have none at all in InVesalius - so
chances are good that I made mistakes. Just fix them in SVN!
> :: Remarks
>
> 1. InVesalius is licensed only by GNU GPL 2 (not above) - this is
> really important because GPL2 is already translated to Portuguese, and
> according to Brazilian law, the license has to be available in
> Portuguese. Although FSF doesn't accept the Portuguese translation,
> that is what is accepted by our legislation. Also, there was a legal
> study regarding GPL 2 that proved it is constitutional... And there is
> no study regarding GPL 3.
So this is simple a bug introduced by me. Feel free to fix any of this
you might notice.
> 2. Although we are the authors, the copyright is of the research
> centre where we work (Centro de Tecnologia da Informação Renato
> Archer), because they sponsored the project.
Simply inject any information which is needed in debian/copyright.
> :: Questions
>
> i. What should we do (on the <control> file) regarding dependencies
> that are not needed, but provide more features to InVesalius? Ins't
> there a tag "Recommends:"? Currently we provide support to Analyze
> files on the command line - but this feature depends on
> python-insighttoolkit_3.16
Yes, please use Recommends for packages which are not absolutely needed.
In fact it is suggested to use hard Depends only for packages which
would make a package absolutely useless if they would be missing. The
packages in Recommends are installed by apt by default if you don't
explicitely ask for leaving them out (as you might like to do on
embedded systems or things like that). So under normal conditions you
can expect the Recommended packages to be installed.
> ii. Is there something like "Authors" on the <copyright> file? Can we add it?
Just have a look at
http://dep.debian.net/deps/dep5/
as specified in the first row of this file. In this DEP5 it is suggested
to use "Maintainers" (I personally see a chance to mix this up with
Debian maintainer, but that's the suggestion I would follow).
And yes, finally you are free to add a field - there is currently
no policy about this and you are free to consider the file as a
free form text file.
> iii. Isn't python-multiprocessing included in python2-6?
That's my fault because I was tricked by the not yet default Python 2.6
and I was running InVesalius under Python 2.5. Perhaps it might make
sense to verify the Python version if you are really relying on 2.6
features.
PLease also note: While I added python-support in the Build-Depends(-Indep)
the package does not yet comply with the Python policy ... I did not yet
finished this step until now.
> iv. Some (Ubuntu) users reported a problem regarding InVesalius
> dependency on python-wxgtk2.8. Apparently if one had a previous
> version of python-wxgtk installed, InVesalius would try to use that
> older version, and not 2.8 - even though 2.8 was also installed. This
> was only solved uninstalling the previous wxgtk version. Do you have
> any guess about this - so we don't need to unistall the previous
> version?
I think Karsten has answered this question yet.
> v. Will these files work under Ubuntu as well?
I think if you follow Karsten's advise it will work under Debian and
Ubuntu (but I admit I'm not sure).
> vi. How should we do when InVesalius needs a new dependency that is
> not available at Debian repository? (e.g. Sigar) or a newer version
> of a certain library (e.g. imagine VTK 5.6 has just been release and
> we decide using it in InVesalius, but only VTK 5.4 is available in
> debian repository...)
Well, care for the needed dependency first. That's hard - but there is
no other option and my guess is that this task is the hardest one we will
have to tackle.
> > Please check this out because the changes will make most probably also your
> > Ubuntu packages better. I would really welcome if you would commit your
> > changes to this repository to cooperate in this packaging.
> >
> Ok, perfect, thanks!
Obviosely not perfect ... but hopefully helpful as well as these hints.
Please trust on this list (no need to CC me personally) the next week
because I'll be on vacation from Saturday on.
> Thanks! I understood most of it. Just one doubt:
> What happened to the original makefile? It is not necessary anymore?
Try
man dh
The line
dh --with quilt $@
in debian/rules does "anything which seems to make sense". Calling the
upstream Makefile is something which just makes sense. Check the
*.build logfile if in doubt.
> How should we use the <10_wrapper_is_bash_script.patch>?
I'd suggest applying it in upstream InVesalius and removing it from the
debian directory. The only reason why I did not yet pointed to it is
that I wanted to see whether further changes might be needed. But it
makes sense to apply it to upstream sources right now.
> Can we (Thiago) pack SIGAR oficially?
Sure. That's the best thing you can do to speed InVesalius packaging up.
> We only would need some advices
> and enhacements... I guess this is something more general, not only
> Debian Med.
Yes. I have seen this. My advise would be to ask on
debian-mentors@lists.debian.org
list. There is much more general packaging expertise than on the Debian Med
mailing list (as on any Debian mailing list you do not need to be subscribed,
but watch the archive).
> SIGAR is a very interesting tool. It is multi-platform (GNU Linux,
> Windows, MacOS,Solaris, among others - both 32-64b) and provides
> several features for analyzing hardware, such as: memory, file-system,
> swap, processor, etc. Despite this, it is available for Java, Perl,
> Python, Ruby, Lua, PHP, among others.
>From my first view there is a need to split up the packages into several
binary packages each for every language interface. You should not force
a user to install all the Ruby, Lua, PHP, etc. stuff if he just wants
the Python interface. That's a sophisticated thing to do and should
definitely be discussed on debian-mentors.
> SIGAR is really needed in InVesalius. We use it to see the system
> configuration and, depending on the memory available and if the OS is
> 32/64 bits, we change the resolution of the image volume, so the user
> can open really large DICOM sequences in a computer that is not that
> good.
OK. When consulting debian-mentors you might point to this thread in the
mailing list archive.
> > Kind regards
> >
> Best regards and good skiing! :)
Yup, thanks. ;-) Seems like in the Alps is less snow than here at home ...
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: