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.