Re: Auto Backporting (Was: Backports of scientific packages)
On Fri, Sep 25, 2009 at 04:39:20PM +0200, Rene Engelhard wrote:
> Hi,
>
> On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> > 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.
>
> build-deps are not necessarily runtime deps.
Sure, and that's why rebuilding is required
> Especially if
> stuff changed in the fs or for policy reasons and that is not reflected in the
> build-deps because the change is not in the build-deps.
Surely, in such cases, the resulting binaries should depend on something
that is not in stable. In such case, either backport this what is not in
stable, or mark the package as not backportable.
> Same for depends.
>
> Or do you (build-)depend on a newer menu for the menu changes stuff?
Depending on the kind of changes, you probably should.
> or will you depend or conflict against all myspell/hunspell dicts
> in stable with ice*? No, you would want to revert that changes to run
> on stable smoothly.
In which case the package is simply not automatically backportable.
Anyways, I don't think this needs an extra control field, especially
considering this will end up being an "opt-in" field. If a field may be
necessary, probably an "opt-out" one would be better.
But I still think that checking for Build-Deps will give a first list
of potentially autobackportable packages, out of which a huge amount
will probably work out of the (autobuild) box, and only a few will need
some adjustments. And this lists really ought to be handled out of
debian/control, IMHO.
> > As a side note, some packages are "easily" backportable, in the sense
> > that they only require a few build-dependencies to be backported. This
> > is the case for xulrunner and iceweasel, where only sqlite needs to be
> > backported for the packages to be backportable.
>
> Actually, xulrunner and iceweasel are bad examples, since they will
> be involved in the hunspell dictionary location transition. A rebuild
> will make them look in a location which does not even exist in stable.
> (Yet that transition has to be done for squeeze)
Well, at least the *current* packages are just fine. But you are right
to point out these, because I do think we, as a whole, are not careful
enough at these details when disrupting the places where files are
installed vs. the according {build,} dependencies updates.
Mike
Reply to: