On Friday 30 October 2015 10:20:58 Gary Dale wrote: > I can understand why "unstable" users may want it, but that doesn't > those of us using testing are a different breed. We want to help get > things ready for the next stable release. That means helping to identify > bugs that could cause problems for people wanting stable software. And that's exactly what has happened here. A (single) component entered testing when it shouldn't have (only together with the other pieces that are needed). I understand that it's frustrating mostly because the impact is rather big, but the actual problem is rather small. > However we can't report bugs on software that doesn't work at all. The GUI/Plasma didn't work. It is indeed a lot harder to figure out and report on _what_ is broken when the tools you're (most) familiar with aren't working at that time. That's why you need IMO to be rather proficient to do things on the CLI in order to run testing (and even more so for unstable). The incredible stability of testing (and unstable) of recent years is both a blessing, but also a curse as it has distorted the ideas/expectations of those releases. When you're running testing you need to be able to fix a non-working GUI using CLI tools only. That means keeping old versions of packages available so you can downgrade in case things fail. Either you keep old versions around in a location of your own or use /var/cache/apt/ (thus be very careful with 'aptitude clean/autoclean') or know how you can get packages from snapshot.debian.org _without_ the use of gui tools/browsers. In this regard you can say that users of unstable have it easier because they can downgrade to the testing versions of packages rather easily (I always have both testing and unstable in my sources.list). > Why the push to get KDE5 out when it is still having massive teething > problems? Plasma 5 didn't enter testing after 5.4 iirc so that's a lot more conservative then with KDE4. But because of KDE Frameworks 5 there are now a LOT more (but smaller) packages and thus figuring out the exact (packaging) relationships has become more complex and as you've noticed, some of those issues only pop up when a component enters testing without the ones that that component also needs. My suggestion is to take this as a learning opportunity and figure out, when things are working fine, how to deal with a situation when things break like they just have been. While these breakages should occur less and less over the release cycle of stretch, expect them not to be over just yet. One way to deal with it could be to add the unstable sources to your APT config (but default to testing), so you can upgrade more packages to their newer version and report whether that would solve the issue.
Attachment:
signature.asc
Description: This is a digitally signed message part.