[conspire] How to update packages when Deb is behind?

[Rick Moen]

Paul -- 

Now that I've had some coffee and opportunity to ponder this matter a
bit, I would still advise caution and a bit of detective work to
guesstimate what condition you're system's in and how it got that way,
but can outline a couple of alternative paths forward.  Which one you
should take might hinge on some details of your intentions.

To review, you installed from (some) Debian-installing media in 2015.
Somehow between then and now, you've ended up with a system that thinks
it's following the Debian 'testing' rolling-distribution track
(currently Debian 10 'buster'), rather than the Debian 'stable'
release-oriented track (currently Debian 9 'stretch').  You either do or
do not rely on one of the big Desktop Environments such as GNOME3, a 
potential complicating factor.  (The Official Debian ISOs, if used to
install a desktop system, default to GNOME3 as the path of least
resistance, but that is hardly the only or IMO best way to run desktop
Linux using Debian.)

(Late update while writing this:  You now are mentioning that it's
LXDE.)

Adding to the uncertainties on my end, I'm still a bit unclear on
whether you've done much in the way of routine software updating on this
system since 2015.  Reviewing again (and showing my bias towards simple
and reliable command-line tools, though there are other ways), an admin
might do this merely by carrying out these two commands as the root
user, once every week or so, to update the entire system to the latest
for the track specified in /etc/apt/sources.list:

# apt-get update
# apt-get dist-upgrade

(Note for Linux beginners reading along.  The '#' is not something to
type, but is a documentation convention meaning 'Type this thing at a
shell prompt where you are the root user', leveraging the tradition 
that the root user's shell prompt normally ends in a '#" character.
Likewise, '$' in the same place would mean 'Type this thing at a shell
prompt where you are a normal user', with the same rationale.)

apt-get's 'update' operation refreshes the catalogues of software
available for installation on the various remote apt sources referenced
in sources.list.  Its 'dist-upgrade' is one of a couple of operations 
to bring all of the system's installed software up to date with the
referenced apt sources referenced in sources.list.

Both commands will yield voluminous output.  Any time progress stops to
advise you of something and seek your feedback, you are strongly advised
to pay close attention.  The maximally cautious approach would be to
also do the commands within a subshell launched by the 'script' tool,
which by default logs all terminal I/O to file 'typescript' in the
current directory.  (ctrl-d or 'exit' closes the subshell, as usual.)


Pick a Strategy
---------------

Here is where you can/should assess what you're system's been doing and
what you wish to do with it going forward:  Basically, you can either
flesh out the existing sources.list and converge your system to the 
constantly evolving 'testing' track, or you can attempt to converge 
it to the release-oriented 'stable' track.

You basically need to pick ones of those two options.  _If_ the current 
installed software versions are significantly more recent than those in 
Debian 9 'stretch' (current Stable), then an attempt to converge to
Stable won't go well -- because, in short, downgrading in Debian 
isn't officially supported and can be done only with a good bit of work.
Making the attempt to converge onto Stable requires just editing
sources.list to have contents appropriate for Stable, and then doing the
aforementioned apt-get dance.

If you want to attempt the Stable converging, and things seem amiss at
the end of doing so, fortunately, you would then still have the option
to change your mind and converge onto Testing, instead.  

Or, of course, you could decide that Testing is what you had in mind all
along, just flesh out source.list to show full contents appropriate for
Testing, and do the apt-get dance.  It should be that simple, but note
caveats below.

sources.list Examples
---------------------

Here are typical source.list contents for Stable:

  deb http://deb.debian.org/debian stable main contrib non-free
  deb http://deb.debian.org/debian stable-updates main contrib non-free
  deb http://security.debian.org/debian-security/ stable/updates main contrib non-free
  #deb-src http://deb.debian.org/debian stable main contrib non-free
  #deb-src http://deb.debian.org/debian stable-updates main contrib non-free
  #deb-src http://security.debian.org/debian-security/ stable/updates main contrib non-free

Unless you are doing significant building of packages from source code
packages, just leave the three deb-src lines commented out.

The equivalent sources.list for Testing is just the same, except with
track name 'testing' where track name 'stable' occurs above:

  deb http://deb.debian.org/debian testing main contrib non-free
  deb http://deb.debian.org/debian testing-updates main contrib non-free
  deb http://security.debian.org/debian-security/ testing/updates main contrib non-free
  #deb-src http://deb.debian.org/debian testing main contrib non-free
  #deb-src http://deb.debian.org/debian testing-updates main contrib non-free
  #deb-src http://security.debian.org/debian-security/ testing/updates main contrib non-free


Use of Track Names; Use of Mirror Hostnames
-------------------------------------------

Some examples urge using in sources.list the named branches named for Toy
Story characters (stretch, buster, etc.) instead of the track names
(stable, testing, etc.) -- and long, tedious arguments can be found
about this on the Internet.  I would say use a track name consistently
unless and until you have a good reason to do otherwise, and are clear
on what you're doing and why.  (You really don't want to wake up one day 
to realise you're now on an EOLed Debian branch that you hammered into
sources.list five years ago and forgot about.)

Your current sources.list uses hostname mirrors.ocf.berkeley.edu (where
the above examples use deb.debian.org.  Nothing wrong with that.
Possibly around the time you first installed, some piece of software
guesstimated that mirrors.ocf.berkeley.edu is a pretty fast Debian repo
mirror from your location.  FWIW, the deb.debian.org appears to be the
newest of a series of schemes to use geolocation and load-balancing,
etc. for apt requests.  See:  http://deb.debian.org/

So, e.g., doing a search-and-replace in the apt-get examples to
substitute mirrors.ocf.berkeley.edu for deb.debian.org would work fine.


Anyway:

Caveats
-------

1.  Gosh, be super-careful with sources.list contents.  Doing crazy
things with that file is probably the most common express lane for
screwing up a Debian system, and the ways to fux0r it are legion but
include:

(a) throwing in questionable unofficial apt sources without serious
contemplation

(b) mixing in lines from both the Stable and Testing branches.
While Unstable=sid and the Testing branch are extremely close in their 
package versions, the same is not true of the (wide, problematic) gap in
package versions between those two tracks and the Stable one.

The Testing track is something of a software mirage, actually.  One
might argue that it's merely a filtered version of the Unstable=sid
rolling-distribution track, which is the reason the package versions are
just about identical.  Procedurally, what happens is that package
maintainers upload their new package source releases, and the Debian
build masters then build them for all supported architectures and, if
compilation completes, propagates the binary packages out to the master
repos where they immediately appear in the Unstable track (Toy Story
name always pinned to 'sid', the name of the neighbour kid who breaks 
toys).  Each night on the Debian repo infrastructure boxes, a
quarantining script also runs that applies some automated quality
criteria to all newly released packages popping into Unstable.
If those criteria are met, then the package likewise pops into the
Testing rolling release.  If not, then the new & shiny release of that
package will be installable for systems tracking Unstable, but not yet
those tracking Testing.

The above is why:

2.  The Testing branch can create some package maintenance bobbles for 
systems relying on complex package-dependency snarls such as the big
Desktop Environments.  While I was writing this, you clarified that 
your system relies on LXDE.  LXDE is by far not the worst
package-dependency hairball.

I'm guessing that LXDE is on your system courtesy of presence of a
metapackage called 'task-lxde-desktop'.  See:
https://packages.debian.org/testing/task-lxde-desktop
That, in turn, depends on metapackage 'lxde'.  See:
https://packages.debian.org/testing/lxde

The 'dep' lines on those Web pages indicate hard package dependencies,
and some dependencies have dependencies, et cetera, et cetera.

The 'bobbles' can come on one fine day when you attempt the apt-get
dance, and suddenly LXDE package foo cannot be currently upgraded to the
newest version in Testing because package libbar version N is required
but only version N-1 is available in Testing.  This typically happens
because the latest release of package foo recently cleared quarantining
into Testing, but related and required new version of dependency library
libbar had quality problems and thus made it into Unstable but not yet
into Testing.

This bobble can typically be overcome by waiting a couple of days and
trying the apt-get dance again.  _Or_ you can (carefully) do a trick 
and add Unstable branches into sources.list but ensure that they are
normally unused unless specifically invoked in a custom apt-get command
option, by setting a low 'pin-priority' for that apt source.

I'll not cover that now, because this follow-up is already long enough,
but I can do so if you're interested.