#2165 dcmtk 3.5.4

closed-duplicate
Daniel Macks
5
2009-05-29
2005-12-23
Bernd Kuemmerlen
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.

Discussion

  • Daniel Macks
    Daniel Macks
    2005-12-23

    • milestone: 373615 --> 373614
     
  • Daniel Macks
    Daniel Macks
    2005-12-23

    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)

     
    • milestone: 373614 --> 373615
     
  • 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)

     
  • Daniel Macks
    Daniel Macks
    2006-03-07

    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!

     
  • Daniel Macks
    Daniel Macks
    2006-03-07

    • milestone: 373615 --> 373616
    • assigned_to: nobody --> dmacks
    • status: open --> closed-accepted
     
    • milestone: 373616 -->
    • status: closed-accepted --> open-accepted
     
    • labels: --> Updated Version of Existing
     
  • 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

     
  • 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?)

     
  • jedfrechette
    jedfrechette
    2009-03-16

    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.

     
    • milestone: --> Force_rebuild_extant_pkgs_req
    • status: open-accepted --> closed-duplicate