Re: Auto Backporting (Was: Backports of scientific packages)
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. 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.
Same for depends.
Or do you (build-)depend on a newer menu for the menu changes stuff?
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.
> 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)
Grüße/Regards,
Rene
--
.''`. René Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' rene@debian.org | GnuPG-Key ID: D03E3E70
`- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
Reply to: