On 2015-11-03 at 09:40, Alex Moonshine wrote: > On 11/03/2015 04:06 PM, The Wanderer wrote: >> >> So far, the only structural problem I've had with testing has been >> in the grub-related packages, in the form of longstanding open >> bugs reported by people whose computers became unbootable after a >> grub upgrade (which may have been related to the transition away >> from grub-legacy); I've had those packages set on hold for what >> seems like years now, ever since those bugs first appeared, to >> avoid the risk of this computer getting into a similar state. Even >> this hasn't caused me any practical problems, however. > > How about packages that are not in testing, because they or their > dependencies have bugs that prevent pushing them down from unstable? > You're lucky you're not using any. OP does (filezilla). What do you > recommend him to do? Either install the version that's in stable (since there's zero harm in tracking stable + testing, vs. tracking just testing), or - if that would cause too many dependency problems - install it as a one-off package from sid. As I said, installing a single package as a one-off is one matter, but tracking sid as a whole is entirely another. > What if it isn't filezilla? What if it is xorg-server? It might > happen. Testing isn't meant to always be usable. Well, unstable isn't > as well, but it switches from unusable state to usable MUCH faster > (days, as opposed to weeks). It switches from obviously unusable to not obviously unusable much faster, perhaps, but its failure states are much sneakier and harder to recover from. >> (Well, aside from temporary breakage due to package transitions >> such as the recent lib*v5 mess. That's just a matter of "wait a few >> weeks before dist-upgrading", though, which isn't unreasonable; it >> seems unlikely that most people will want to dist-upgrade multiple >> times a week the way I usually do outside of a release freeze.) > > How about waiting a few weeks before dist-upgrading on sid? Solves > all problems just as well. No, not really - because in those few weeks, the odds of something else significant getting broken in sid are much higher than the odds of another such transition happening in testing. Such transitions tend to be fairly rare; I'd consider it odd for there to be even a handful of them (large enough to be noticeable) in one year. Not to mention that the odds of _not noticing_ that something got broken are much higher in sid than in testing. "Package not installable" is easy to spot, has no real negative repercussions on an upgrade (since you can see it in advance and cancel / postpone the upgrade), can be worked around manually with comparatively little difficulty, and tends to be fixed in the course of routine operations; the problems in sid tend to be more subtle, much harder to spot in advance, and much harder to fix once they've gotten themselves in place. When tracking testing, the biggest problems you're likely to encounter can be fixed by simply waiting for new package versions to reach testing (and/or possibly a bit of cleverness with the package manager). I have encountered this several times, but it's never been critical or fatal, and it's never lasted terribly long. When tracking sid, the biggest problems you're likely to encounter cannot easily be fixed in-place at all; you're likely to need to reinstall Debian from scratch. I have encountered this twice, and that's more than enough. The latter is, IMO, by far the worse of the two possibilities. > There's an essential package called apt-listbugs that you HAVE TO use > when running either sid or testing. Of course, and I do use it. (As well as apt-listchanges, because not all changes which I might find objectionable would get classified as bugs. Some are actively intentional, such as aspects of the systemd mess.) >> I think I can see what you're interpreting as "recommends unstable over >> testing" in that document, but only barely. It's certainly not a bald or >> unequivocal recommendation, unless I'm missing something. > > 3.1 Which Debian distribution (stable/testing/unstable) is better > for me? > > If security or stability are at all important for you: install > stable. period. This is the most preferred way. > > *If you are a new user installing to a desktop machine, start with > stable.* Some of the software is quite old, but it's the least buggy > environment to work in. You can easily switch to the more modern > unstable (or testing) once you are a little more confident. > > *If you are a desktop user with a lot of experience in the operating > system and does not mind facing the odd bug now and then, or even > full system breakage, use unstable. * It has all the latest and > greatest software, and bugs are usually fixed swiftly. > > There's no advice to install testing at all, for any user (because of > the same reason - the package that you need may just not be there). There's a _big_ gap between "new desktop user" and "desktop user with a lot of experience in the operating system, who does not mind facing full system breakage"... > I would also invoke the opinion of Raphael Herzog (the author of > Debian Administrator Handbook) > https://raphaelhertzog.com/2010/12/20/5-reasons-why-debian-unstable-does-not-deserve-its-name/ > > You, of course, are entitled to have your own opinion, nothing wrong > with that. I tend to concur with the view expressed by the person posting as "Seeker" in the comments on that post. Yes, sid is usable, but it is not safe to use - period, full stop. If you are tracking sid, things _will_ break occasionally, and have to be fixed - not just in the repositories (e.g. package-dependency issues such as the ones in the gcc5 transition), but on your computer, unless you're lucky enough to have someone else trip over them and report the bug before you install the broken version. If you are tracking testing, things may break occasionally - but it's far less likely that the breakage won't be noticed before making it to your computer than would be the case in sid, simply because sid provides an additional layer in which such breakage can be noticed and reported before it ever has a chance to reach you. >> I would certainly not recommend that _anyone_ run sid on their >> primary computer, much less on their only computer. Installing a >> single package as a one-off is one thing (and I occasionally do it >> myself), but - as the name implies - sid is, and probably always >> will be, too unstable to be safe for general use. >> > I've been running Sid as my main daily driver for >3 years with > little to no issues. I suspect that either you really do have issues under the hood which you just haven't noticed yet (I certainly did, after using it for a similar time period), or you're much more knowledgeable and careful (and micromanage-y) about your upgrades than most people. Or else you've just been lucky. > Not saying that everyone can or should. AM saying that those who > can't should run stable, NOT testing. I strongly disagree on that latter point. testing is much safer than sid, in terms of the types of breakage it sees and how easy it is to avoid such (or to fix them after the fact), while not being stuck on potentially years-old outdated software as stable can be. > But, well, I guess different things work for different people. Some > folks do use Arch, for example. ^_^ -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature