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 ([EMAIL PROTECTED]) [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]