[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dcm2niix

On Wed, 2017-01-11 at 11:22 -0500, Yaroslav Halchenko wrote:
> Hi Ghislain,
> Thanks for packaging and uploading to dcm2niix!

You're welcome.

> It is a pity though that we duplicated the effort somewhat since
> we maintained dcm2niix within NeuroDebian for a while and didn't upload
> primarily due to some licensing issues we brought up with upstream and
> which were later resolved (e.g. of console/ujpeg.*)

Before packaging a piece of software for Debian, I systematically check
whether an ITP has already been filed for it on the Debian BTS. There
was none, so I went for it. The duplication is a pity, but I can't be
blamed for following the standard procedure for contributing a new
package to the archive.

> It would be nice to converge and co-maintain a single package, may be
> under some team, e.g our pkg-exppsy (neurodebian) team or  debian-med --
> whatever you would prefer

I believe the package should be maintained by the Debian Med Team, and
subsequently backported to Debian Stable and Ubuntu LTS by NeuroDebian,
if desirable. The primary source for derivative projects should remain

> our packaging is present on alioth and github:
> git://git.debian.org/git/pkg-exppsy/dcm2niix.git
> https://github.com/neurodebian/dcm2niix


> unfortunately there is a stumbling stone on our end also -- versioning
> since upstream was inconsistent and I was naive to switch from our
> custom 0.0.date to their 'date' scheme they took for earlier
> releases, and now they have switched to 1.0.date ... heh


You are referring to the following issue [1], right?

[1] https://github.com/rordenlab/dcm2niix/issues/28

> correct resolution, to account for poor us NeuroDebianoids would be to
> introduce an epoch making it 1:1.0.20161101  so currently present
> version in neurodebian (20160921+git16-g0339407-1~nd+1) would upgrade to
> it.
> What do you think? ;)

Well, do I really have a choice?

An alternative solution could be to convince Chris to revert to the old
YYYYMMDD versioning scheme. This way both the Debian and NeuroDebian
packages can be upgraded without such hack. He is about to make a new
release so we should act fast.


Reply to: