Hi Steve, On Sun, Aug 9, 2009 at 4:56 AM, Steve M. Robbins<steve@sumost.ca> wrote:
Thanks for packaging dicom3tools; I'm eager to have them in Debian.
:)
On Sun, Aug 09, 2009 at 01:13:59AM +0200, mathieu.malaterre@gmail.com wrote:I think I have hit an issue with the dicom3tools debian packaging. The main author think -for good reasons- that this is a bad idea to distribute binaries which will create invalid DICOM file as I have done in the package.What is the issue, precisely?
The full thread can be found here: http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/719f2662d40e5c63 What I'd like to emphazise is that I *did* communicate with upstream maintainer, so this quite a surprise to me.
Does the tool create invalid DICOM inadvertently, or is it a tool designed to generate invalid DICOM for testing purposes? I can't see any problem with the latter, especially if that's the intent of the unmodified upstream source code.
Well this is an issue for the upstream maintainer. I do understand his point of view and as main -and very well respected- author, I followed his suggestion and only ship read-only command line tool. there are other toolkit to generate DICOM file. The only tool I can think of that is not provide in other implementation (dcmtk, gdcm) is dcuncat.
My question is simply: (1) Once package is uploaded, can I just make another release on top of it to destroy any evidence that there is a way to access some dicom3tools cmd line tool that the main author do not wish to distribute as binary ? (2) Or should I somehow stop the review process to make sure none of the binary gets uploaded ?The package is still in NEW, but I believe you can make a second upload of the same revision and it will be overwritten. If that doesn't work, you can definitely make a revision -2 upload; both will appear in the NEW queue and should be processed together.
As suggested by Nelson, I choosed to increment the version number. Thanks, -- Mathieu
Attachment:
signature.asc
Description: OpenPGP digital signature