Re: Why are backports of Squeeze packages in etch-backports?
* Ondřej Surý <ondrej@sury.org> [2009-03-02 16:23:53 CET]:
> On Mon, Mar 2, 2009 at 16:13, Dominic Hargreaves <dom@earth.li> wrote:
> > It's probably a bit late now if this policy has been inacted, but I'd
> > like to vote *against* it.
>
> I don't consider this as problem, since it was announced here before.
That doesn't mean that one has to agree with that approach.
> And you can always stop receiving updates from bpo before it happens.
It's not always as obvious. Yes, backports is said to contain
backported versions from testing - personally I (and others as expressed
here) would prefer it to have that changed to contain backported
versions from the (usually upcoming) next release. Principle of least
surprise. One might have pulled a package from backports because of a
specific feature need and wouldn't want to track backports after the
next release again because the feature then is already in the new
stable.
> > Not allowing such backports would indeed make direct upgrades to lenny
> > much easier, and it seems a great shame to risk breaking upgrades in
> > this way.
>
> If you keep etch and lenny bpo in sync - you can always upgrade from
> etch+bpo to lenny+bpo and it shouldn't pose a problem.
It shouldn't pose a problem, but it's not something that everyone would
want or is looking for.
Thanks,
Rhonda
Reply to: