Re: dicom3tool on task page
On Tue, 16 Dec 2008, Mathieu Malaterre wrote:
I know I ask about that before, but I can't remember what I need to
change so that the status of dicom3tools on:
http://debian-med.alioth.debian.org/tasks/imaging.html
is updated.
Well, technically you have to touch
svn://svn.debian.org/svn/cdd/projects/med/trunk/debian-med/tasks/imaging
and I guess you would like to mention that there is some packageing stuff
available which moves it to the "yellow" section. I just did so now and
mentioned you as responsible. I also copied the long description as second
paragraph to the description of this entry. I'm not completely happy about
your short description "Dicom3tools Software" which is a bit less. I would
suggest you issue an ITP bug now via
reportbug wnpp
and try to find a good description for the package which can be better
understood by non DICOM experts.
Regarding the package resulting from your commits in SVN:
1. The package contains some static libraries in /usr/lib.
This is typical for a development package. If this makes
sense we should spilt the package into a package with the
binary tools and a dicom3tools-dev package - but I guess
it needs the accompanying header files as well.
If you have no idea how to build multi binary packages
feel free to ask me for help - I just need the information
whether it makes sense at all and which header files are
needed. I don't think that we need the *.a files in the
tools package.
2. Considering the fact that there are some static libraries
I simply suspect / wild guess that the size of the files
in /usr/bin is that large due to the fact that they are
statically linked. Does the build process enable a creation
of dynamic libraries and dynamic linking of the tools in
/usr/bin against these?
3. Considering the fact that /usr/bin contains 127 executables
I wonder whether no name clashes to other packages exist.
We should probably verify this. A usual way to circumvent
this problem would be to install these files to
/usr/lib/dicom3tools
and provide a wrapper which sets PATH to this directory.
4. Some manpages are empty and trigger lintian bugs. They
seem to be autogenerated I have no idea whether this
autogeneration process just failed or why they are empty.
At least they should not be installed and optimally overriden
by some real manpages. Moreover this automatical process
triggers a manpage-has-bad-whatis-entry lintian warning.
It might be that this can be fixed as well - even if this
has lower priority than the other remarks.
Kind regards and thanks for your work
Andreas.
--
http://fam-tille.de
Reply to: