Re: When Debian 4.1 will arrive... will anyone care?
On Fri, Apr 20, 2007 at 03:17:34PM +1000, Craig Sanders wrote:
> On Sun, Apr 15, 2007 at 10:23:58PM +0200, Andreas Schuldei wrote:
> > * Wouter Verhelst (wouter@debian.org) [070415 21:01]:
> > > I think testing already supports that to some extent, and that the bits
> > > where it does not can be worked on. Creating another branch does not
> > > seem like something useful to me.
> >
> > but it is requested a LOT by people who have to run stable (huge)
> > installations with some new apps on top. php is a popular
> > candidate to have from backports on a lot of big german hosters,
> > for example. If they could help somehow they would, as debian is
> > dominating the market completly and this is a very common
> > problem.
>
> why the obsession with backports?
>
> contrary to popular belief and self-delusion, 'stable+backports' is NO
> LONGER STABLE.
True.
> the only 'advantage' to using 'stable+backports' over 'stable+some
> packages from unstable or testing' is that you don't have that nasty
> label 'unstable'.
Not true. A package built on unstable requires libraries and other
dependencies from unstable or testing, which gets more and more
problematic as the release goes on. A package built for backports
requires libraries from stable where reasonably possible.
> to get that crucially important 'benefit', you're using packages from
> a repository with unsigned packages by unknown maintainers.
Not true either. Backports is signed, and only Debian Developers can
upload there.
> IMO, if you need a 'stable' system with some newer packages, you're
> better off learning how apt's pinning stuff works than bothering with
> backports. it's not hard.
The only problem with that is that you then get a whole shitload of
problems once libc or other dependencies are no longer in sync with
stable. As is the case right now. At that point, you start getting those
libraries and their dependencies out of testing or unstable rather than
stable. That's a slippery slope that rather quickly ends you up with a
testing system rather than a system running stable "plus a few packages
from someplace else".
Since packages for backports are built on stable, because the
requirement for a package to be in backports is that it be built against
packages from stable (except where not otherwise possible due to the
newer code using features from libraries that are not in stable), you
don't have that problem there. The slippery slope here still exists, but
is not as bad.
That's not to say using backports is without its problems (there are
some backports-specific issues, mostly in upgrading), but I don't agree
with the statement that you're necessarily better off with apt pinning.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: