[svlug] Migration to Debian

Scott DuBois rhcom.linux at gmail.com
Mon Jan 5 12:16:13 PST 2015

On Sat, Jan 03, 2015 at 04:15:41AM -0800, Rick Moen wrote:
> 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.

Agreed, I do realize that KDE is one of the biggest, bloated, DE's one can
choose to work from and I've considered simply installing a bare core
distribution then adding in something like blackbox to handle GUI stuff. I'm
just not quite there yet though. Maybe next time around as long as I can
continue to use the proprietary BS that's currently being forced on me.

>From reading the 2004 archives and the way you 'pinned' your repo's to get the
benefits from both testing and unstable, I can really see some great advantages
to that. Although, one must admit, it's an extreme edge case of advanced
'hacking' to achive the gretest benefits from a distribution. Is there a
significant amount of maintenance involved regarding, say, broken or missing

> 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.

'Moving Day' will be rather interesting. At the moment, I'm less interested in
making sure I have the 'latest and greatest' program releases involved as long
as I can achieve the necessary results; Acroread for my protected books,
LibreOffice to write my papers and save as .doc without formatting issues,
email, watch blu-ray, my printer works, my web cam works, blah blah blah.

> > 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.)

With 'buntu, I got updates on like a 'constant' basis. About every other day a
half dozen or more bug fixes, updates, upgrades, or whatever would roll in. This
level of frequency just seemed somewhat irrational to me. Maybe a couple a week
or something but every other day? Nah. Yeah, one can roll with the 5 year LTS
version but there was still a significant amount of maintenance required to keep
it all working. Those who roll with the 6 month turn around are just absolutely
crazy (IMHO).

The concept I like behind stable is that as I add new software and get it all
configured the way I like and am happy with, I don't necessarily have to concern
myself with a 'new' release being pushed on me a few days or weeks later that
'may' break everything I just set up. AS I ride this out through the next
release (I think Jesse), I'm interested to see to what level everything sustains
itself. As in, what will break and what will simply 'roll' into the new released
versions. When I was using OpenSUSE, a release update meant a shitload of
breakage that I would have to manually go in and do emergency package repair.
The distro is _really_ nice when it's stable and working, but there were a few
releases in 2012 that were just freaking awful because they were pushed out to
meet deadlines rather than be thoroughly tested first. I'm sick of that kind of
shit. 'F' the damn deadlines and give me something that isn't f-ing broken!

> 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.)

I'd much rather prefer to get it 'when it's ready' than at some predetermined
schedule that might crash because it hasn't been thoroughly tested yet. =)

> 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).

If I get to the 'doldrums' point, I will definitely ask first before doing
anything crazy. At the moment, I have _no_ intention of swaying from the stable
branch for anything. I have everything installed and configured that I really
'need' at the moment short of getting blu-ray up and running and verifying that
my webcam works. There _might_ be a few other things that are eluding me at the
moment but, I will address those as they come along and only utilize what
sources I require from the stable branch or multimedia additions to such.

> 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:

Hence the reason I was on Kubuntu and actually pretty happy with it for the most
part. Lots of support and development out there for 'buntu and derivs including
a plethora of proprietary supply if one so chooses. The bad sid to this is the
amount of maintenance required to support such a cluster of haggled software
without breaking shit.

> 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?'

I 'might' be a Fred, who knows. It's still early in the game and at the moment,
I'm pretty happy with knowing there is little chance of breakage that I don't
induce upon myself.

>From looking some things up, I'm definitely going to add backports though. =)

> 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.

As such is the first and foremost reason I wanted to switch to Debian stable and
get a taste for the 'mild' side in lieu of the 'wild' side. I believe in good,
quality, QA. I don't agree with corporate influenced scheduled releases of
inferior products; ahem Vista.

More information about the svlug mailing list