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

Re: About backports.



On Mon, 10 Aug 2015, Charles Plessy wrote:
> > Like you indicated, that's not the only concern. On behalf of stable
> > release users, I think making a recent version of samtools available in
> > stable-backports is important-- I think the backports repository is a
> > huge reason why Debian stable is usable for everyday purposes (and it's
> > the main reason why I switched to Debian from Ubuntu for my own machines).

> Backports are definitely great, and the requirement that a backported package
> must have been in Testing is both an asset for the quality and a limitation for
> the logistics.  In some cases, Testing migration is completely out of our
> control, for instance with the GCC5 migrations currently.

> I sometimes wonder if it would be better to have a separate repository for
> providing Debian Med packages to Stable users.  Ideally it would be a Debian
> PPA, but these are not developed yet.

> The big advantage that a separate repository would have over the traditional
> backports, is that it would allow us to also distribute some packages for
> Stable without rebuidling them, when they pass their regression tests on
> Stable.  This would make such a backport archive much more comprehensive.

FWIW, this is our approach in NeuroDebian:  whenever possible enable build-time
testing, then build and upload at the same time to both main Debian archive
sid, and NeuroDebian -- backports for anything supported (Debians and Ubuntus).
Everything is streamlined with some elderly scripts (now in neurodebian-dev
package) around cowbuilder:

sudo nd_build4debianmain *dsc --hookdir=$HOME/neurodebian/tools/hooks && { sudo nd_updateall; sudo nd_build4allnd *dsc; }

So if it FTBFS for debian sid, I fall into that environment to troubleshoot it
etc.  If passes -- all build envs get updated, and I build backports for all of
them.  Above generates summary.build which tells which builds succeeded, and
where failed I look into corresponding .build file to see what needs to be
fixed.

This is of cause straightforward for leaf packages... if package is used
by other packages, and I suspect that it might cause various FTBFS and/or tests
failures, I usually also run "downstream" regression testing by rebuilding all
its dependees against old and new versions of the package [1] on Debian sid and
stable if I aim to upload backports. 

[1] http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/nd_build_testrdepends

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
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        


Reply to: