[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dicom3tool on task page

On Tue, 16 Dec 2008, Mathieu Malaterre wrote:


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.

Sounds good.  Do you think I should update the information on the
tasks page manually or do you bet that the package will be uploaded soon
and we obtain the information from the official package control file?

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.

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...

That's debhelper magic. ;-)

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...

I have seen the prefixing but there are also other names.  So just checking
for name clashes seems to be a good idea.

     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...

I mean if it turns out that there will be some zero byte man pages
created by whatever automatical tool we should prevent their installation.
It might be even better to provide simple manpages which were written
manually - but maintaining the other things I mentioned above is more

Thanks for your work



Reply to: