[Debian-med-packaging] mriconvert packaging / NeuroDebian derivative

Steve M. Robbins steve at sumost.ca
Tue Feb 12 03:36:14 UTC 2013


On February 11, 2013 03:42:41 PM you wrote:

> FWIW -- i.e. if you care/interested -- I have uploaded backport builds
> of .250 to neurodebian for nearly all debian/ubuntu releases.  To do the
> backport I obviously had to lower build-depends on dh and itk.  Here is
> the patch (below) I will now carry under debian/patches for the
> use with  our
> http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob;hb=HEAD;f=tools/
> backport-dsc to patch while backporting for older releases.
> 
> I wondered, since the patch and all the symlinks to it (per each
> distribution) are kept neatly under debian/patches and do not anyhow
> interfere with official packaging -- would you mind "adopting" it into the
> official SVN for mriconvert? Since it is under the team maintenance -- I
> could even commit it myself if you would not mind.

I haven't looked at how you do neurodebian backports.  Is it simply a set of 
patches with the prefix "nd_"?  And some magic in your build process?  My first 
thought was that it sounds benign and could be put into the standard debian 
source tree.  

On second thought, however: what happens when Debian makes a new release?  The 
patches would tend to need updating.  Which would mean changing the Debian 
sources again?  Have you done this already with some other package?  

Maybe the better model is to treat NeuroDebian as a derivative like Ubuntu is, 
where they maintain a diff against the Debian version.  How is the Debian 
backports maintained?



> Also, it might be better in the longer run, if build-depends in
> debian/control were multilined -- with our patching in mind that would
> provide sufficient number of content lines around while getting away from
> "volatile" Standads-Version etc ruining our patching ;)

Sounds fine.  Feel free to make that change.


As for the patch itself: the build-depends was changed from

	libinsighttoolkit4-dev
to
	libinsighttoolkit3-dev|libinsighttoolkit4-dev

which worries me that the build is no longer predictable as to which ITK it is 
built with.  I'd suggest changing to simply libinsighttoolkit3-dev.  In fact, 
I had planned to do that anyway with the next Debian upload since ITK 4 is not 
available on many architectures at present.  So feel free to do that in the 
main repository and then you won't have to patch it :-)

Regards,
-Steve



More information about the Debian-med-packaging mailing list