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

Re: Auto Backporting (Was: Backports of scientific packages)



On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> On Fri, Sep 25, 2009 at 12:58:00PM +0200, Manuel Prinz wrote:
> > 
> > Yes. I like the idea but we simply can't rebuild everything from the
> > task pages of these blends since there are also tools from KDE or GNOME
> > which would mean to backport quite a lot of unrelated stuff. Also,
> > packages with code in interpreted language can almost always be used
> > directly from testing. But I think auto-building could work for a
> > well-defined subset of packages.
> 
> IMHO this problem is not really Debian Science or Blends related and the
> idea to handle backports analog to non-free autobuilds sounds quite
> reasonable - but in this case we *really* make it analog tp non-free which
> works with a debian/control field
> 
>     XS-Autobuild: yes
> 
> So why not using a similar field
> 
>     XS-Autobackport: yes
> 
> ?  Well, it's definitely not that easy but I see a quite large set of
> packages (specifically in the Debian Science field) which perfectly
> compiles against Build-Depends of stable.  If we could handle this set
> automatically for a first shot and think later about those packages
> which need Build-Depends which are not available in stable this would
> be an interesting thing.
> 
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way. 

One problem is that unlike non-free autobuilds, auto-backports should
happen once the package enters testing, not unstable.  Otherwise, users
tracking this auto-backports repository will basically track unstable
for the applications they use and will get burnt by zero-day
grey-paper-bag uploads or otherwise unstable software.

As such, a facility more like the binNMU triggers for the release-team/
buildd-maintainers might be better; i.e. wait till a package hits
testing, then evaluate its impact and trigger an auto-backport via
wanna-build something else.  Of course, at that point, doing a manual
backports.org upload is not too far off, effort-wise.


Michael


Reply to: