On Sun, 08 May 2016 07:18:40 -0400 The Wanderer <wanderer@fastmail.fm> wrote: > On 2016-05-08 at 03:45, Neil Williams wrote: > > > On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard <linkfanel@yahoo.fr> > > wrote: > > Even if running unstable, I would certainly expect that something > which is known to break certain types of systems this badly would be > announced at package install time, giving me a chance to cancel the > install... It's unstable - I've been running unstable on my main development laptop for ten years, most of the time that something has broken my system, I've had to be the one to report it! Some of those bugs have caused this level of breakage. It's also an issue of workload and whether there is a realistic likelihood of that breakage. The expectation is that users of unstable are not running production systems and that changes like this can be introduced in unstable with notices on d-d-a and - if those changes are to get into the release, the release notes. Some of the problems can be anticipated (package migrations etc.) and even some of those go wrong. The rest of the problems in unstable only become apparent to the maintainer after a bug has been filed. Some of these problems could disable packages completely but what happens is a bug report for the version in unstable and a fix in unstable. That's how unstable works. When unstable does break like this, users of unstable need to be ready to downgrade packages themselves, debug the failure themselves, write sensible bug reports and contribute to stopping that breakage getting into testing. Unstable does, sometimes, generate a high level interrupt, I don't see that this is something that can be avoided. That's why unstable is not suitable for production systems. I haven't had that many interruptions whilst using unstable, overall, but enough that I strongly advise any production system to use stable with backports or possibly testing. > and the more so considering that people keep talking about > tracking sid as being a reasonable thing to do, although I myself > decided years ago from experience that it was a bad idea. The purpose of sid cannot be fulfilled if nobody uses it but those who do use it have to accept being the front line for the problems that need to be fixed before causing problems in testing (and thereby backports & the next stable). With current migration priorities, those using unstable only have 5 days to upgrade and test the upgraded packages. Upgrading unstable once a month doesn't work, once a week is sub-optimal too. I still enjoy having unstable, I use it to preempt problems in stable and backports (where my production systems do rely on things working). Unstable is not suitable for production systems itself and it makes no sense to try and turn it into some kind of second testing. (Personally, I wouldn't use testing on production systems either - unless the number and scale of the backports to stable make that unmanageable.) -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpTXdRrgWqKX.pgp
Description: OpenPGP digital signature