Re: dicom3tool on task page

[Andreas Tille <tillea@rki.de>]

On Tue, 16 Dec 2008, Mathieu Malaterre wrote:

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

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

Thanks.

> > 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 :)

Yep.

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

Thanks for your work

       Andreas.

--
http://fam-tille.de