On Tue, Dec 16, 2008 at 8:57 PM, Juergen Salk <[email protected]> wrote: > * Mathieu Malaterre <[email protected]> [081216 11:38]: > >> For my next task, I'd like to take on dicomscope packaging. Because >> of the way it is build, the src code need to be moved within dcmtk. So >> my question is: >> >> Is it ok for a package to download two tarballs. reshuffle the second >> one in the first one, and present just a single tarball as a new >> enhanced 'dcmtk' package ? > > No. DICOMscope should depend on the dcmtk package version that is > already available in Debian rather than throwing in an ancient > dcmtk version in addition to the one that is already there.
At what point in my message did I say I would be using an old version of dcmtk ? All I am saying is that for building dicomscope, I would like a new (meta)package src package which would contains both dcmtk (3.5.4 + debian patch) and dicomscope (with any required patchs). > I know that - in its current state - DICOMscope 3.5.1 will > presumably compile out-of-the-box with dcmtk version 3.5.0 only. > But it would certainly be possible (and very creditable) > to adapt the DICOMscope 3.5.1 JNI classes to the current dcmtk API ... That's my goal. > On the other hand: DICOMscope 3.5.1 is an ancient version by > itself (last update in 2001 or so). I doubt that upstream would > adapt your changes to DICOMscope 3.5.1 as they already provide > DICOMscope 3.6.0 as a binary package. Clear enough. > Would be interesting to > know if they are going to make its sources available as well > somewhen ... I received the confirmation that this is not going to happen any time soon. -- Mathieu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
