Re: Auto Backporting (Was: Backports of scientific packages)
* Mike Hommey <mh@glandium.org> [090925 16:06]:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > 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.
>
> Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> And if it doesn't build that way, I'd say there's a bug in the package
> anyways, because it should bump some build dependencies.
Often that is enough, but often things change in a way not expressable
(or not expressed) in Build-Depends.
For example backporting to etch means to change the menu item back to
the old layout for everything that has a menu item.
Between lenny and squeeze there might be similar changes. The difference
between calling install-info and having a trigger for that, for example.
As that is usually done using debhelper, that is no problem backporting
virtually all packages. But a package not using debhelper for this would
most likely not have any build-dependency avoiding a non-functional
package being produced in lenny.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: