Re: Packaging of aeskulap for Debian and dcmtk issue

[Andreas Tille <tillea@rki.de>]

[Because I did not found any private issues in your mail I'm risking
 violating the netiquette and answer in public to the Debian-Med
 mailing list.  I hope you will excude this which is done for the
 profit of all projects to get more possible input on this topic.]

On Tue, 13 Nov 2007, OFFIS DICOM Team wrote:

> Dear Andreas,
>
> > I think aeskulap is a nice target for an official Debian package because
> > it would nicely enhance the medical imaging section of the Debian-Med
> > effort ( http://www.debian.org/devel/debian-med/imaging ).
> > When I had a look into the latest source tarball of aeskulap at
> >     http://www.bms-austria.com/~pipelka/aeskulap/aeskulap-0.2.2-beta1.tar.gz
> > I noticed that it includes a complete copy of the dcmtk source with some
> > patches that looked after a quick view not harmful regarding an integration
> > into official dcmtk.  I just want to know whether there was some contact
> > between both project authors?  If we would like to integrate aeskulap into
> > Debian it would by a really bad idea to include just another copy of dcmtk
> > into Debian.  So my question is: Would the dcmtk project accept those
> > patches that are included in aeskulap and could the aeskulap image
> > viewer just use the official dcmtk project stuff?  Regarding maintainance
> > and security it is definitely a bad idea to copy code around and thus
> > I would be very happy if this could be avoided.
>
> speaking for the DCMTK project, I can say that we would not oppose to the
> integration of a patch that makes DCMTK more useful for a project such as
> aeskulap, if the patch is not harmful for the overall project.
>
> There has been no contact between our team and the aeskulap developers,
> and we were not aware of this patch.

The aeskulap author Alexander Pipelka explained that he is including the
copy of dcmtk just for the comfort of his users and that there are no
essential patches.

> That said, I have run a diff between aeskulap-DCMTK and DCMTK 3.5.4 release,
> and there are hardly any changes in the source code. Below's a complete(!)
> diff (mostly for my collegues in CC). These are trivialties.

Which just proves the statement of Alexander.  So I stick to my opinion
that copying and duplicating code is basically not a good idea and the
Debian source tarball will not include this copy.  So the author is free
to do what he feels is necessary - but perhaps leading his users to
pre-packages binaries of dcmtk would be the better alternative.

> All other changes are either due to a rebuild of the autoconf script with
> an outdated version of autoconf, or changes to the Makefile system.
>
> Obviously the aeskulap authors have patched the Makefiles to create shared
> objects instead of static libraries (something which is not supported by
> the standard DCMTK configure script since we don't use libtool).

Well, I have to admit that I'm happy that the Debian package contains
shared libraries and a development package containing headers and
static libraries.  This Debian policy is quite convinient and I would
like to suggest to take over this packaging stuff which IMHO would be
an enhancement.

> However, the changes are "hard coded" to only support GCC and to only
> support Posix systems, because GCC specific command line options have
> been added to the Makefile unconditionally, and there are calls to the
> ln command which obviously does not exist on all operating systems.
> This is a modification we cannot copy into a project that supports a
> multitude of operating systems and compilers, and building a platform
> independent replacement is not exactly trivial (which is the reason
> why it's not there in the first place).

Perhaps the Debian packaging patches do show the same restriction
and I have to admit that I have no idea whether this is a libtool
constraint or whether it is just a suboptimal implementation of
the libtool technique.  In case you are interested I might ask on
the Debian developers list whether there is a portable solution
that fits your needs while building static and dynamic libraries
as well.

> So, while I'm open to suggestions, I don't know exactly what to do on
> that part.

Well, regarding the Aeskulap issue there is obviousely nothing
to do on your side, because the patches are negligible.  For
the portable creation of static and dynamic libraries we might
discuss about this in case you are interested.

Kind regards

        Andreas.

--
http://fam-tille.de