Menu
▾
▴
#2165 dcmtk 3.5.4
closed-duplicate
5
2009-05-29
2005-12-23
No
This is a new upstream version of dcmtk, the DICOM
toolkit from OFFIS.
Some words on the toolkit itself: This is a set of libs
and tools to handle medical image data in the DICOM
(Digital Imaging and COmmunications in Medicine) format
which is the standard used by almost all medical
imaging modalities.
I have tested this package on 10.4, using GCC 4.0. It
does not work on 10.3 with GCC 3.3 at the moment, so it
is intended only for the 10.4 tree. It should replace
the current dcmtk 3.5.2 in the sci section.
There are two different packages, one "standard" which
is compiled with libtiff, libpng and libxml support
(needed for some of the tools), and one ssl-package
which in addition is linked against OpenSSL for some
extended security features.
I have run 'fink -v validate' on both packages, and
both the info and deb-files are OK.
Logged In: YES
user_id=535292
Good solution for the gcc4 problem! A few thoughts...
1. If you are enabling png and xml and have
BuildDepends:libpng3,libxml2, are libpng3-shlibs and/or
libxml2-shlibs needed at runtime (and therefore need to be
listed in the Depends field)?
I see some issues in these .info that appear to be carried
over from the existing packages (so they may need some fixes
in the old version remaining in the 10.3 tree too).
2. It looks like you're doing a bunch of juggling in
InstallScript in order to move the directory installed at
%i/share/doc down into %i/share/doc/dcmtk. Would it be
cleaner to just patch the "docdir" value in
config/Makefile.def.in?
3. Does the dcmtk package really disable openssl? According
to ./configure, you may need to pass an explicit flag to
disable it. Otherwise, it appears to be auto-detected,
meaning if a user happens to have openssl097* installed, the
non-ssl package will get ssl anyway.
4. A Conflicts/Replaces/Provides trio that lists something
that is also a real package doesn't work correctly (either
in fink or in the underlying Debian tools). That is, you
have dcmtk-ssl listing dcmtk, which also exists in its own
right, as opposed to having dcmtk-ssl and dcmtk both list
some third name. It's not usually observed as a bug by users
unless there are other packages that Depends on it though.
Logged In: YES
user_id=420044
Thanks for your thoughts... I am still a little unsure about
a lot of the stuff when creating a fink package, so this
helps a lot.
> 1. If you are enabling png and xml and have
> BuildDepends:libpng3,libxml2, are libpng3-shlibs and/or
> libxml2-shlibs needed at runtime (and therefore need to be
> listed in the Depends field)?
You are right... when I first checked this with your
fink-dep-check script, nothing else was listed, but it seems
that I didn't have the right package installed then... I
will fix this!
> 2. It looks like you're doing a bunch of juggling in
> InstallScript in order to move the directory installed at
> %i/share/doc down into %i/share/doc/dcmtk. Would it be
> cleaner to just patch the "docdir" value in
> config/Makefile.def.in?
You are right, it is even easier (and perhaps cleaner) to
supply the proper dir-arguments to make. I will try this.
> 3. Does the dcmtk package really disable openssl?
> According to ./configure, you may need to pass an explicit
> flag to disable it. Otherwise, it appears to be
> auto-detected, meaning if a user happens to have
> openssl097* installed, the non-ssl package will get
> ssl anyway.
OK...
> 4. A Conflicts/Replaces/Provides trio that lists something
> that is also a real package doesn't work correctly (either
> in fink or in the underlying Debian tools). That is, you
> have dcmtk-ssl listing dcmtk, which also exists in its own
> right, as opposed to having dcmtk-ssl and dcmtk both list
> some third name. It's not usually observed as a bug by
> users unless there are other packages that Depends on it
> though.
What is the correct way to do this? I think these fields are
in the info because somebody (drm?) mentioned it when I
created the first dcmtk-package.
Logged In: YES
user_id=420044
Here's an update version of the package:
- comments 1.-3. from dmacks have been addressed
- I added another package dcmtk-doc, which contains the
html-documentation of the dcmtk toolkit (this is not
installed with the other packages)
Logged In: YES
user_id=420044
Forgot:
- this update also contains a patch from the debian package
to fix the installation location of a file (dicom.dic), see
http://forum.dcmtk.org/viewtopic.php?t=572 for more information
Logged In: YES
user_id=420044
I got a report from a user that my dcmtk-ssl 3.5.4 package
(which is submitted, but not yet included) fails during
installation with the following error:
Unpacking dcmtk-ssl (from
.../dcmtk-ssl_3.5.4-2_darwin-powerpc.deb) ...
dpkg: dependency problems prevent configuration of dcmtk-ssl:
dcmtk-ssl depends on gcc4.0; however:
Package gcc4.0 is not installed.
dpkg: error processing dcmtk-ssl (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
dcmtk-ssl
### execution of dpkg failed, exit code 1
Failed: can't install package dcmtk-ssl-3.5.4-2
I have not seen this problem, and I have a few questions
about this:
- I have a Depends:gcc4.0 in my info-file. I think I did
this because the packaging manual states "and a dependency
on one of the (virtual) gcc packages should be specified."
Is it correct, or should the dependancy be Build-Depends?
- Why does dpkg complain about the missing gcc4.0 package on
the user's system, but not on any of the systems where I
tested it? Why does it complain about a virtual package at all?
Logged In: YES
user_id=420044
It seems that gcc4.0 must not be a Depends but a
BuildDepends setting. Thanks to Alexander Hansen for
pointing this out.
I fixed this in version 3 of the package (attached)
Logged In: YES
user_id=420044
Another update: With the help of the upstream developers, I
finally managed to put together a version which does compile
under 10.3 with GCC 3.3
The 10.4-package is the same, but I re-packaged the tar.gz
files to be able to distinguish them here (amd it seems that
the last attachment didn't work anyway...)
dcmtk and dcmtk-ssl for 10.3 (gcc 3.3)
dcmtk and dcmtk-ssl for 10.4 (gcc 4.0)
Logged In: YES
user_id=535292
I think adding a GCC tag automatically sets CXX to the
corresponding g++ compiler, but no harm in making it
explicit. Similarly, you don't need a BuildDepends on the
"normal" gcc* package for a given tree.
CVS chill is over, so I'll add these now and if you submit
an update for some other reason you can consider changing that.
Also, we're apparently adding 1000 to the 10.4 (gcc4)
package revisions so that the lower trees' packages can be
upgraded without colliding, so I made the 10.4 pkg
Revision:1001.
Thanks for the updates!
Logged In: YES
user_id=420044
Originator: YES
This is an update of the dcmtk 3.5.4 package for MOSX 10.5. In addition to the previous version, I had to patch configure.in and add an autoall call to the build script.
In addition to the two smaller changes mentioned by dmacks in the last comment, I also updated the package to get rid of the -ssl variant according to http://wiki.finkproject.org/index.php/Getting_rid_of_-ssl_variants_by_using_system-openssl-dev
File Added: dcmtk-3.5.4-1002-10.5.tar.gz
Unified dcmtk for 10.5 (gcc 4.0)
Logged In: YES
user_id=420044
Originator: YES
Oh, I just noticed that I don't know if "1002" would be the right package revision for 10.5, or if there is another major jump (2001?)
What is the status of this ticket? This appears to be the original submission which has been marked as resolved-Accepted so perhaps this ticket should be closed and a new ticket opened with the 1002 update.
Closing this one in favor of https://sourceforge.net/tracker/?func=detail&aid=2796355&group_id=17203&atid=414256