Re: dicom3tool on task page
'lo
On Tue, Dec 16, 2008 at 12:51 PM, Andreas Tille <tillea@rki.de> wrote:
> 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.
Fixed.
Description: Tools for handling DICOM files, with conversion from
proprietary formats.
Unix, Mac and Windows (Cygwin) command line utilities for creating,
modifying, dumping and validating files of DICOM attributes, and
conversion of proprietary image formats to DICOM. Can handle older
ACR/NEMA format data, and some proprietary versions of that such as SPI.
> 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.
done.
> Regarding the package resulting from your commits in SVN:
>
> 1. The package contains some static libraries in /usr/lib.
cool, that means the patch works on your station too :)
> 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
:) not an expert but becoming one shortly I guess. I did for teem and gdcm.
I was simply surprise the package was generated properly in
dicom3tools, while I did explicitly wrote any *.install file, and I
did no wrote any explicit "dh_install ..." in the rules files...
> 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?
Not that I know of. I'll wait until David Clunie comes back from
vacation and I'll check with him on how to proceed. I am not an imake
expert (at all!)
> 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.
Most of them have the single 'dc' prefix versus the 'dcm' prefix from
dcmtk. So we should be ok. But I agree it is a bit confusing. We could
also have a dicom3tools and a dicom3tools-extra package...
> 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.
Neither do I. I'll check with D. Clunie.
> 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.
I do not understand that...
Thanks,
--
Mathieu
Reply to: