Re: dicomscope 3.6.0 / debian package
On Fri, 9 Jan 2009, Mathieu Malaterre wrote:
A quick update. I am done with the packaging of dicomscope (I
think). Thanks to the help of the OFFIS team, I integrated the 3.6.0
release of there dicomscope. So even if the latest available src zip
from their ftp server is 3.5.1, in the end the package will contains
all bug fixes and new features from the 3.6.0 release ! Big thanks to
OFFIS team for that !
many thanks for your work on this and it is really great to hear about
active upstream projects.
'active' :)
dicomscope 3.6.0 was released ~2003
Well, active in the sense that they suported your intent. That's
sometimes hard without unresponsive upstream.
It should be possible. However it looks like cmake does not work out
of the box with openjdk-6-jdk.
Your patch seems to work. Just have a look at my changes.
I tried a patch (I cannot test, as I am
on stable here), could someone please report any issue ?
Running stable is fine. You might consider running a pbuilder instance
with unstable (or maintain an unstable chroot manually but I would like
to advise pbuilder or cowbuilder as a wrapper).
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?
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 ...
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?
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.
- 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.
After installing the package the program at least starts - I personally have
no idea what you might do with this programm.
Kind regards and thanks for your work
Andreas.
--
http://fam-tille.de
Reply to: