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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
