Re: dicomscope 3.6.0 / debian package
On Fri, 9 Jan 2009, Mathieu Malaterre wrote:
-> Would you be able to write a (short) manpage for /usr/bin/dicomscope?
will do.
Great. I think we might go with an upload once this is done even if
the other issues are not settled down (but should try to fix at least
the lintian errors later).
E: dicomscope: no-shlibs-control-file usr/lib/libjInterface.so
-> 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.
Would you mind asking on debian-mentors or debian-devel for advise?
In most cases you get a helpful answer.
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).
OK. Thanks for clarification. I'll think about a dicom-data or
dicom-common arch independent package then and we should probably
override the lintian warning about the different package name.
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 ...
Could you please move this information more clearly to README.Debian?
- 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...)
This sounds like dscs35.pdf should go into a separate package. Would
you suggest a reasonable name and description for this? I'd volunteer
to care for the multi binary packaging which might be a harder job for
you than for me.
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).
Did you made up your mind about kradview? At least it is actively developed.
I started with the packaging after I came back from Malaga where I met
upstream, but have stalled the work (for a reason I do not remember -
probably because I moved gnumed-server on top of my todo list and come
back if nobody else steps in).
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.
I just have to trust you in every DICOM related question.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: