[svlug] Migration to Debian

Rick Moen rick at svlug.org
Sat Jan 3 04:15:41 PST 2015

Scott DuBois wrote:

> Still working with KDE as a DE.

First thing to realise is that, for better or worse, KDE4 is one of the two
biggest dependency hairballs in open source, the other being GNOME.  This
has the consequence that, for all practical purposes, it must be upgraded as
a suite rather than piecewise.  Your staying on the Stable branch will keep
the suite functioning without upgrade snarls, at the cost of you having
rather old release versions of all of the constituent programs.  At some
point, you may find the Stable branch's policy of picking a version ofay,
Konqueror deemed maintainable for the lifetime of the release, and applying
to it only bugfixes and backported security patches rather than upgrades to
new versions, to be frustrating.  You may start getting restless, sitting in
the doldrums.

On the bright side, doing 'apt-get update && apt-get dist-upgrade' every few
days will bring in blessedly small downloads 99.9% of the time, the 0.1%
exception being the day Debian cuts over Stable to a new release (e.g.,
Squeeze to Jessie), in which case you'll suddenly get an amazing flood of
updates, gears whir, and suddenly everything is (briefly) a lot less
ancient, then the long period of dust-settling begins again.  

'Stable' tends towards the tranquil except for the brief disturbance on, er, 
moving day.

> I'm interested to experience how often and in-depth updates are released.

As to frequency of release, Ghod Only Knows.   (I don't know what you mean
by 'in depth' in this context.)

Sometimes, Debian has gone as long as (from memory) three years between
Stable releases.  First, the Release Manager has to declare that there are
no release-critical bugs any more, not just on one CPU architecture but on
all of them.  This was a huge obstacle back when Debian insisted on
simultaneous release on (from memory) 13 or so different architectures. 
In the last couple of years, a few of them have been dropped or relegated to
second-citizen status where the release isn't delayed as a whole just
because packages available on some highly obscure CPU architecture still
have release-critical bugs.

If you poke Debianistas about 'When's the next release?', their traditional
answers are 'When it's ready' and 'Sooner if you help'.  (Yes, it does
qualify as a Frequently Asked Question.)

You should be aware that all of the 1000+ Debian developers (which is mostly
but not exclusively a grandiose term for package maintainer) don't run
Stable themselves.  They run Unstable, which is the raw form of the rolling
distribution.  A third branch, Testing, is actually the same as Unstable
except with the effects of a nightly quarantining script on the ftp master
machines, such that packages appearing after maintainer upload in the
repositories for Unstable also populate into Testing if and only if they 
pass automated quarantining criteria to assess package quality.  The
criteria are applied on each individual package, not on any suite of which
that package may be a part.

This is where KDE4 and GNOME being package hairballs is relevant:  As I
explain in the three 2004 postings whose URLs I cited, the consequence of
this is that a bunch of KDE4 applications might at a particular moment may
not be upgradeable (or freshly installable) on the Testing branch, because
the packages for those applications have all passed quarantine themselves,
but the required version of libfoo, which they all require, is still stuck
in quarantine because, say, it doesn't build at the moment on the MIPS CPU
architecture.  You don't care about MIPS, but the necessary libfoo version
simply isn't yet in Testing because of that build failure.

For people trccking Testing, I provide in those URLs I cited my preferred
workaround, where you make your Testing system able to pull down on request
packages from Unstable (and meet their dependencies from Unstable), without
changing everything from Testing versions to Unstable ones.

This trick works well to mix Testing and Unstable, because they are quite
close, hence compatible.  Do _not_ under any circumstances yield to the
temptation to pull down Testing or Unstable packages (and their dependency
trees) onto Stable, or you are likely to make a shambles of your system.  
Doing that is a common novice error.  Instead, as you start to feel hemmed
in by the doldrums that is Stable, try backports.org before being tempted to
do anything more rash (and system-breaking).

When even backports.org ceases to cure your newer-app envy, you can do what
I did many years ago, and leave Stable behind, switching to the Testing/Unstable
rolling release as a much better platform.  For reasons described, this
works best if you are not determined to use KDE4 or GNOME (or probably
Xfce4, either), and is better-suited for users who eschew DEs - because of
their dependency-hairball proclivities.

Testing/Unstable is most definitely not the doldrums, but in my experience
the quality is consistently very high, such that it's the sweet spot.  By
the time you're ready to  consider the rolling releases,  methods for doing
so without being migrated onto systemd will probably beasy and not
require instruction recipes linked from
http://without-systemd.org/wiki/index.php/Main_Page .

As a point of interest, the situation I describe above of challenges to
running some DE suites on Testing/Unstable, along with Debian's stubborn
'When it's ready" approach to releases and willingness to hold release
hostage to obscure CPU platforms, is the reason Canonical created Ubuntu --
because he wanted to meet the needs of a certain class of DE user the Debian
developers are unwiling to unbend enough to make happy:

Consider a KDE4 user Fred who installs Debian Stable.  Fred is relatively happy
for a while, although the default desktop's a bit dowdy and could user some
better theming.   Fred eventually goes onto #debian and says 'Hey, the
packages on Stable are sure kinda old.  Is there a way to fix that?'

Fred gets Standard Debian Answer #1:  'If you wish, you can get updated
packages by adding backports.org repos to your system configuration, and
installing from those repos  However, be cautioned that backports are not
official Debian packages, any quality or security concerns are your problem,
and please don't seek recourse from us about them.'  Fred tries this, but
comes back not quite satisfied, and says 'I've tried backports.org, but they
don't have everything I want, and I'm troubled by them not being official
packages.  Surely there's a way to get more-modern app versions _and_
official packages.'

Fred now gets fed Standard Debian Answer #2:  'You could switch tracks from
Stable to to Unstable and/or Testing and remain there.  Of course, if you do, 
if you encounter problems, those just sometimes come with the territory, and
the Debian Project canot be responsible for your encountering them.  Less
technical users, those unwilling to encounter and deal with occasional
maintenance issues or package quality problems, are suggested to remain on
the Stable branch and enjoy full support.'

Fred considers this, but is unsure whether he is willing to take that leap.
He has an idea, and comes back to #debian a third time.   'I hear that
Jessie, the current Testing branch, is in code freeze and nearing release,
which means that I might consider jumping to it but remaining on it after
release.  I guess I could do that by changing repo references to squeeze or
stable in /etc/apt/sources.list and /etc/apt/sourcses.list.d/* to 'jessie'.
When is jessie going to be released.

Standard Debian Answer #3:  'When it's ready / Sooner if you help.'  Fred at
this point is developing the strong, justifiable suspicion that he and other
desktop users wanting both leading-edge app versions and official support
are being 'handled':  They're offered modern versions only if they
acknowledge that they are not permitted to whine about any breakage.  Fred
develops a sneaking suspicion that Unstable has that name primarily to deter
complaints from novices chewing up developer time, because it's actually
pretty reliably stable.  Fred estimates that his type of user just isn't
Debian's target market.  In all of these suspicions, Fred is correct.   The
developers actually don't want to handhold desktop users at all, frankly,
and they're all on Unstable.

Shuttleworth founded Canonical to give people like Fred a solution and give
his firm a modest revenue stream from paid support.  Instead of 13+ CPU
platforms, he decided to focus on only the three relevant to desktop users.
(PowerPC was later dropped.)  Package selection in the 'main' repo, the only
repo eligible for paid support, was kept to a core of central package s for
each DE that Canonical's support staff could be experts on.  DE packages in
the 'main' collection were treated as suites, not QA'd individually.  These
three adjustments, in turn, permitted Ubuntu to announce that it was going
to stick to a six-month release schedule come hell or high water.  Which, by
the way, they've stuck to, though QA has sometimes slipped because of that.

More information about the svlug mailing list