Re: dicomscope 3.6.0 / debian package
'lo
On Fri, Jan 9, 2009 at 2:41 PM, Andreas Tille <tillea@rki.de> wrote:
...
> Here are the remaining issues:
>
> Lintian:
> W: dicomscope: binary-without-manpage usr/bin/dicomscope
>
> -> Would you be able to write a (short) manpage for /usr/bin/dicomscope?
will do.
> E: dicomscope: no-shlibs-control-file usr/lib/libjInterface.so
> N:
> N: Although the package includes a shared library, the package does
> not
> N: have a shlibs control file. If this is intentional, please override
> N: this error.
> N:
> N: Refer to Policy Manual, section 8.6 for details.
>
> -> Unfortunately I have not the slightest idea what might went wrong
> here. Perhaps we should ask on debian-{devel,mentors} for help ...
same here. the jar file is loading the shared lib at runtime, so this
is not a usual C executable linked to a shared lib...maybe this is not
handled as it should.
> I: dicomscope: arch-dep-package-has-big-usr-share 3304kB 89%
> N:
> N: The package has a significant amount of architecture-independent
> data
> N: in /usr/share, while it is an architecture-dependent package. This
> is
> N: wasteful of mirror space and bandwidth, as we then end up with
> N: multiple copies of this data, one for each architecture.
> N:
> N: See also:
> N:
> http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata
>
> -> It might make sense to provide an arch independent package
> dicomscope-data to reduce disk space and bandwidth of mirrors.
> I did not really made up my mind what might be the best solution
> here. It might perhaps be also reasonable to provide a package
> libjInterface with the dynamic library (to respect
> W: dicomscope: package-name-doesnt-match-sonames libjInterface
> which I would override otherwise) and make the dicomscope package
> containing wrapper, jar, tcl as architecture independent. Could
> you give any hint whether a seprate libjinterface - perhaps with
> a less generic name - might make any sense for other purposes than
> dicomscope?
Definitely not. This is only provided to bridge java to the dcmtk c++
API. Even if you were doing another Java program requiring dcmtk in
some way, I would say this is too much dicomscope oriented (I only
briefly browsed through the code).
> Other:
> - README.Debian:
> Please stick to the usual scheme of other README.Debian files (title,
> end with date, length of line < 80 characters), fix spelling.
> Moreover it finally remains unclear whether you are providing version
> 3.5.1 + bugfixes is provided or the real 3.6 as README.Debian says.
> That's somehow confusing.
This is 3.6.0. But I fear that claiming that at debian level (in
debian/changelog) would lead to an infinite number of -uninteresting-
email exchange to get things working (uwatch...).
So until the OFFIS team actually provide the zip file on *their* ftp,
I'll stick to pretending this is a 3.5.1 release. Most of the docs
(eg. pdf still claims this is 3.5.1), so ...
> - Please clarify how important the provided PDF documentations might
> be for the user. It might make sense to provide a separate
> dicomscope-doc
> package if there might be users who might live without the doc.
dsum351.pdf is user oriented. dscs35.pdf is what make the whole value
of dicomscope and only required for advanced user (hum... dicomscope
user are advanced user anyway...)
> After installing the package the program at least starts - I personally have
> no idea what you might do with this programm.
:)
Any other "DICOM viewer" I have seen out-there are at best buggy (in
debian distrib). dicomscope is the only viewer that actually
implements the DICOM standard (esp. Presentation State). I was getting
annoyed seeing packages claiming being to be "DICOM viewer", so I
decided to work on dicomscope to provide a pretty darn good
alternative to expensive vendors specific system (PACS).
Eg. gdcmviewer which is part of gdcm is part of what I call "buggy"
DICOM viewer, this is more of a dev/debug tool than a professional
solution.
--
Mathieu
Reply to: