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

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

> Now that my afternoon coffee, my sources.list was already close to your
> suggestions.
> Change the mirror names.
> My file had "testing" instead of "stable".
> Two of my lines are now an exact match
>
> Somehow, I am missing contrib and non-free from your suggestion.
> deb http://deb.debian.org/debian stable-updates main contrib non-free

I infer that you have now opted to re-converge onto Debian Stable.

To explain about contrib and non-free:  The Official Debian installer
asks whether you wish to enable those package collections, and the
default answer is 'no'.

The contents of non-free are fairly obvious:  It's all packages whose
licence terms don't comply with the Debian Free Software Guidelines
(DFSG, essentially identical to, and the source for, the Open Source
Definition), but that are nonetheless permissive enough that Debian 
is permitted to lawfully distribute the contents and install/run 
it in a way that complies with Debian policy.

The contents of contrib are also easy to explain, albeit the collection
name is opaque:  It's all packages whose contents themselves are
DFSG-free, but depend on related packages that are proprietary (or, in
Debian jargon, 'non-free').  'contrib' is a pretty dismal term for this
concept, but if you try to think of a better one, you will doubtless
understand the naming problem.


> Before I proceed,  can you explain /etc/debian_version and
> /etc/issue.  I expect those are the real cause of my situation.

I expect those are more _effect_ than cause.

Here's a partial candidate reconstruction of events:  In 2015, you 
performed an installation using some Official Debian installation media,
opting for LXDE as your Desktop Environment.  (You never said which 
installation you used, but that is a plausible surmise.)  During
installation, you were asked whether you wished to enable access to 
proprietary packaged software (non-free and contrib collections), but
took the default choice of 'no'.

As you'll see on http://linuxmafia.com/faq/Debian/debian-releases.html, 
that very likely was one of the Official Debian 8.x 'jessie' images.
'jessie' was at that time the Stable branch, but in the interval since
then, Debian 9 'stretch' has been released (become the new Stable
branch) and 'jessie' consigned to track label 'oldstable' instead of 
'stable'.

At some point between that 2015 date and today, somebody, perhaps you,
monkeyed around with your sources.list contents, changing the existing
track/branch reference to... whatever it then was, 'stable' or 'jessie'
or something, to 'testing', and commenting out almost everything,
leaving just one deb line and one deb-src line uncommented.

(I used, here, the phrase 'monkeyed around with' advisedly:  Doing that
sort of thing is dangerous to your system's continued operation, and
you should take care that that not recur.)

Subsequent to that, at least once, you have done 'apt-get update', which
among other things resulted in adjustment to /etc/debian_version and
/etc/issue to say 'buster/sid'.  

I'm a tiny bit puzzled by the particulars of the above-cited string, or
more precisely I'm failing to remember part of the explanation of what
determines the versioning shown in /etc/issue and /etc/debian_release.
I do remember _part_ of the puzzle, which is that /etc/debian_release
failing to include a version _number_ like '9.0' means that, when that
file was written, the cited Debian version (buster, in this case) didn't
yet have a release number assigned to it, which at least traditionally
in Debian history happened only when they were unlinked from the
'testing' symlink on the package repo machines and relinked to 'stable'.
(Yes, I do mean that 'stable', 'testing', 'unstable', and 'oldstable' 
are literally implemented as symlinks in the Debian repo trees.)

I'm guesstimating that the identification of 'buster/sid' happened
immediately following creation in June 2017 of 'buster' as the new
testing branch, replacing 'stretch' when the latter became the new
Stable branch as Debian 9.x.  

You might be thinking that the reference to 'sid' in this connection
seems not quite right, since 'sid' is the permanent Toy Story name for
the Unstable track (rolling release), and you would be quite right.
I don't know exactly why those got rewritten to say 'sid' rather than 
the obviously more appropriate track name 'testing'.  But as I've
mentioned upthread, the difference between Testing and Unstable is
quite thin verging on a mirage.

And, more to the immediate point, and more helpful to your immediate
needs, one does _not_ edit /etc/issue and /etc/debian_release manually
to change system updating behaviour.  I'm pretty sure that doing so has
no mechanism to produce effects on system maintenance.  The files are,
instead, automagically updated _by_ system maintenance.  So, if seeking 
to re-converge onto Stable, don't worry about those files.  After
re-converging, you will probably find that they've been re-updated to 
reflect the new track selection you forced by editing sources.list and
doing the apt-get dance.




> I will also look at various packages and check the revisions against
> what is in the current stable and testing.  In the case of firefox,
> it is really very old.  I do understand that attempting to go to an
> older version could cause a variety of difficulties.

Using https://www.debian.org/distrib/packages (also reachable as
packages.debian.org (nicknamed 'p.d.o'), which is how I get there, when
I browse the Web), one finds:

o  Latest 'firefox-esr'[1] package in Jessie/oldstable is 52.8.1esr-1
o  Latest 'firefox-esr' package in Stretch/stable is 52.8.1esr-1
o  Latest 'firefox-esr' package in Buster/testing is 52.8.1esr-2
o  Latest 'firefox-esr' package in Sid/unstable is 52.8.1esr-2

ISTR that the results returned by the packages.debian.org search engine
include Debian Security Team updates from _their_ repos, which obviously your
system in its current, overly-pared-down sources.list configuration
isn't consulting at all.  (Which, in case it wasn't clear, would qualify
as A Very Bad Thing.)

How on God's green earth did you end up with version Firefox 45.8.0?
I really have no clue.  Maybe it isn't from Debian's 'firefox-esr'
package.  Maybe you or someone else put in a backported
not-Official-Debian package of Firefox during the days of Iceweasel, or 
something like that.  _Or_ maybe all relevant packagings of
'firefox-esr' since 2015 have been issued via the Debian Security Team
repo, which because of the botched sources.list you've not benefited
from.

Did you check to see what 'dpkg -l | grep firefox' 
says?  And maybe looking at the log entries in /var/lib/apt/ and
/var/lib/dpkg/ using 'zless' would be enlightening, to see what package
operations installed whatever-it-is.


[1] ESR = extended support release.  Since 2012, this has been the
upstream Mozilla codebase you want to favour to stay a bit further away
from the lunatic bleeding edge.  Or, in Mozilla, Inc.'s soothing
PR-speak:  'Mozilla will offer an Extended Support Release (ESR) based
on a regular release of Firefox for desktop for use by organizations
including schools, universities, businesses and others who need extended
support for mass deployments.'  More-meaningful description at:
https://en.wikipedia.org/wiki/History_of_Firefox#Extended_Support_Release