On Fri, Apr 20, 2007 at 05:34:39PM +0200, Frank Küster wrote: > > and the same is true of packages in backports. a serious bug can break > > your system (or, at least, require significant effort to get it back to > > a known good state). > > I argue that the probability of a serious bug in testing, and hence in > backports, is less than in unstable. Moreover, there's an additional > check built in, a person has to decide "this package is fit for a > backport".
a serious bug in testing can last a lot longer than it does in unstable. if a buggy package trickles from unstable to testing before anyone notices the bug and files a report, then (depending on the state of other packages that might be held up, or holding it up) it can stay in testing in that buggy state for weeks before a fix trickles in. in unstable, a new version is there immediately, almost as soon as it is uploaded. testing is not lesser risk, it is different risk. > And it's also safer than running a mix of "stable" with partially > upgraded libraries. but that's what backports is. > > AND, as i said before, anyone with any sense whatsoever will test > > *ALL* upgrades, even the most trivial, on another machine first > > BEFORE applying it to their production servers. anyone who doesn't > > do that should be blaming themselves before they blame either > > unstable or testing or backports. > > There are users who do not own a production server, instead a single > computer, and still feel the need for newer packages. then they should run testing. or ubuntu. i dont get those who whine about debian being old and stale. if they used 'testing' or 'unstable' rather than being scared off by the name, they'd have a system at least as bleeding-edge new as ubuntu or any of the others. and if they choose to use stable then they should quit whinging about it. they have a basic choice - is a stable environment or bleeding-edge packages more important to them? they can't have both, because they're mutually exclusive. choose one. live with the decision, and quit whining. one of debian's big advantages over other distributions was that it is a "live", internet-based, constantly updating system (if you use testing or unstable)...and that upgrades actually work. other dists (esp. debian-based ones like ubuntu) have the same feature now......but we still have debian developers and debian users who refuse to even recognize that it IS a feature. they insist on seeing debian as just the stable release. > > if you're going to attempt lame grammar flames, then at least do so only > > in languages in which you are proficient. > > The fact that you compare backports libraries to *unstable* still makes > me wonder whether you know what you are talking about, grammar or not. > If you'd used "testing" up there, I would not have wondered. And you i've been talking about both testing and unstable all along. it just gets tedious typing 'testing and/or unstable' every time so occasionally i just refer to one of them when i mean both or either. my point remains the same whether it's testing or unstable. just as 'testing' is a variant on unstable, backports is another variant on unstable. it's not less risky, it just has a different set of risks. > won't deny that there are serious breakages in unstable every now and > then, and that they affect testing much less? actually, i've had a lot more trouble with 'testing' systems than unstable. there can be very long delays for packages to trickle from unstable to testing - one important package held up by a bug report can cause dozens of other packages to be held back too...some of them with important bug fixes. in 'unstable', there's a fix for that same problem in the next day or so...in 'testing', it could take weeks. > > sometimes it happens, sometimes it doesn't. it may or may not > > happen. that's besides the point. the point is, you can't count > > on it. tex may have had the upgrade path tested. apache or php or > > whatever may not have. the point is, that the upgrade path from > > backports is far less tested than either 'testing' or 'unstable'. > > That's all true. But this only means that running stable is safer > than running stable+backports. It doesn't say anything about > stable+backports vs. testing (or unstable). i disagree with that too. stable isn't necessarily safer than testing or unstable or backports. it too has its own set of risks. specifically the risk of running ancient software with security holes that no-one has discovered (or backported a patch for) yet or, more commonly, that is incompatible with some other newer software that you might want to run (hence providing the motivation to install stuff from testing/unstable/backports). many times over the years i've seen security updates come in for 'stable' packages, and when i check the version i'm running in 'unstable' find that it was fixed months before or that the conditions required to exploit it aren't possible with that version. i've also seen the occasional security update for stable that isn't yet in unstable....that doesn't last for very long, at least not if a package has an active maintainer. quite often the security update occurs in unstable before it occurs in stable because the stable update is often a backport of a fix in the newer version anyway. security-wise, 'unstable' (and, to a lesser extent, 'testing') is a much smaller risk than 'stable'. IMO *AND* IME. there may be other reasons to stick with stable for a particular machine, but security updates isnt one of them. craig -- craig sanders <[EMAIL PROTECTED]> BOFH excuse #6: global warming -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]