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

Tue Feb 12 14:24:12 UTC 2013

On Mon, 11 Feb 2013, Steve M. Robbins wrote:
> > 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.

backport-dsc script is in the core (Michael even submitted it somewhere
for inclusion but IIRC it was not accepted).

> 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.  

yes -- it is benign.  The only cons -- a bit of pollution of filename space,
e.g. for this case we have:

$> ls debian/patches -l
total 8
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 lucid-dsc-patch -> nd_allow-dh7-itk3.patch
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 natty-dsc-patch -> nd_allow-dh7-itk3.patch
-rw------- 1 yoh yoh 1100 Feb 12 09:18 nd_allow-dh7-itk3.patch
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 oneiric-dsc-patch -> nd_allow-dh7-itk3.patch
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 precise-dsc-patch -> nd_allow-dh7-itk3.patch
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 quantal-dsc-patch -> nd_allow-dh7-itk3.patch
-rw------- 1 yoh yoh    1 Feb 10 19:55 series
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 squeeze-dsc-patch -> nd_allow-dh7-itk3.patch
lrwxrwxrwx 1 yoh yoh   23 Feb 12 09:18 wheezy-dsc-patch -> nd_allow-dh7-itk3.patch

then backport-dsc picks up <RELEASE>-dsc-patch while backporting corresponding
.dsc and applies it before generating the backported source package.  As simple
as that.

nd_build4all sweeps through all "supported" releases of Debian and Ubuntu, and
for each one of them calls nd_build tool which first calls nd_backport (which
calls backport-dsc with preset configuration) to backport source package and
then regular cowbuilder to build it.  So everything is simple (and working) ;)

> On second thought, however: what happens when Debian makes a new release?  The 
> patches would tend to need updating.

unless you keep changing portions of debian/control which get patched -- and if
you keep our backporting patches in the official package -- nothing would need
to be done on our side besides dget + debdiff (analysis of what changed) +
nd_build4allnd

if we are to maintain patches -- I have the git-svn'ed cloned of your packaging
-- so I will maintain a branch containing backporting patches and it will be a
tiny bit more work.

>  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?

primarily we have backports of packages we maintain -- so all backport patches
are just included within official debian source packages ;)  Thus -- no
proliferation of repositories/etc -- all packaging stays together.  There is
only few packages we pick up and backport and usually we do not care to patch
them if they do not seamlessly backport without patching.  If interested in our
"pipeline", see http://neuro.debian.net/blog/2012/2012-04-14_ndtools.html about
our rudimentary wrappers around cowbuilder.

> > 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.

did ... and screwed up ;-) actually git-svn screwed up

I haven't mentioned that it got confused somehow and had 'trunk' following
tags/2.0.250-1 ; so git svn dcommit committed last 3 commits into the
'tag/2.0.250-1' branch instead of the trunk.  

Probably I will redo commits into trunk manually with pure SVN, unless you
would like to switch to use git -- then I would fix my mistake by taking the
burden of converting/fixing in GIT, and commit revert commits into the tag
branch -- unless there is a better way.  What would you advise?  Sorry for the
mess.

These were the commits:

    control: multi-line build-depends, build against ITK 3
    boosted policy to 3.9.4 (no further changes seems to be due)
    rules: added --no-info to help2man call to remove statement about (absent) Texinfo documentation

> 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. 

Yes -- I had similar reservations... but those systems for which it got
backported -- they have no ITK-4 so I felt ok ;-)

>  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.  

good -- did that in the above mentioned commit ;)

> So feel free to do that in the 
> main repository and then you won't have to patch it :-)

;-) see above ;)

-- 
Yaroslav O. Halchenko
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        