On 2017-07-21 19:06, KatolaZ wrote:
> On Fri, Jul 21, 2017 at 11:45:23AM -0400, Boruch Baum wrote:
> > On 2017-07-22 00:23, Ralph Ronnquist wrote:
> > > Boruch Baum wrote on 21/07/17 23:50:
> > > > Where else should I be looking?
> > >
> > > Perhaps you've set "APT::Default-Release "jessie";" ?
> > >
> > > Without that, you'll get the more balanced pinning of 500 and 100.
> > > I think I saw some Debian bug report (on apt?) for this.
> >
> > Thanks, Ralph!
> >
> > That's good news and solved the immediate mystery, but isn't yet an
> > entire solution.

Ok, Ralph, your fix was key, but I had to follow it up with a few
other steps. After some testing, here's some information for the
benefit of the list and other devuan users, about what seems to be
working for me.

1] First some background, The useful command for this scenario is
'apt-cache policy', which displays all the available versions of a
package, each's pin value, which is installed, and which apt would
currently want to install (labeled the "candidate").

1.1] If you are pulling in the translation sections of debian
repositories so that you can benefit from being able to locally read
long package descriptions in 'apt-cache show', you'll find that the
additional entries make it a bit more difficult to read the output of
'apt-cache policy'. For convenience, you can just temporarily comment
out those lines in you /etc/apt/sources.list while evaluating
'apt-cache policy' output, and uncomment the lines afterwards.

2] The only entry in my /etc/apt/apt.conf file was the one Ralph
pointed out was trouble. I eventually deleted the file.

3] Likewise, there were two files in /etc/apt/preferences.d,
'discourage-testing' and 'discourage-backports' that didn't suit my
use case. After testing, I deleted them and incorporated my
alternative into file '/etc/apt/preferences', below.

3.3] My use case is a Jessie install, with occasional needs or
desires for more up-to-date packages, so I need to be able to sanely
pull in and manage packages from backports and testing. I also want
allowance to be able to pull in packages from unstable for when debian
declares a package freeze, which can lock out packages from entering
testing for months (usually there's just a ten day lag for packages to
auto-migrate from unstable to testing).

4] My current file "/etc/apt/preferences" looks like this, and seems
to do the trick. It meets the criteria of my use case, it makes no
wild demands insisting that I do close to the equivalent of a
dist-upgrade to ceres, and it seems to properly decide when to upgrade
packages that had been previously installed with the default devuan
pins of 990 and 500.

4.1] To give you a practical measure of the effect of this solution,
without it 'apt-get upgrade' wanted to install 1,248 packages, and
with this config, just three.


#+BEGIN_SRC conf
# Apt will also pull in pinning instructions from any readable file in
# '/etc/apt/preferences.d', so check there when maintaining this
# function.

Package: *
Pin: release o=Devuan,n=jessie
Pin-Priority: 800

Package: *
Pin: release o=Devuan,a=jessie-backports
Pin-Priority: 750

Package: *
Pin: release o=Devuan,a=ascii
Pin-Priority: 400

Package: *
Pin: release o=Devuan,a=ascii-backports
Pin-Priority: 350

Package: *
Pin: release o=Devuan,n=ceres
Pin-Priority: 200
#+END_SRC

5] That's it! If anyone is tempted to duplicate this, I recommend
waiting as long as you can bear and contacting me off-list for an
update.

> I am very glad you solved your problem, in the end.

Thanks for the (pre-mature) verdict. I solved the problem this afternoon
ago, and included a report above for the benefit of others.

> For the future, please try to be more considerate before rushing to
> report the "incompetent" behaviour of something of somebody else :)

Funny, Why is it that I only get that kind of response from people who
only make useless unconstructive and unhelpful comments? It doesn't
sound that you have been following this thread too closely. The source
of the problem was a line of code pushed by devuan into my
/etc/apt/apt.conf file at some point. My guess, and its only a guess, is
that the issue hasn't been widespread because most user re-installed
from scratch in the transition from beta.

> WithLove

XOXO

> P.S.: Concerning the one thousand-two hundred-and-counting packages to
> upgrade, it looks like your system has remained stuck somewhere close
> to late 2015 or early 2016, so it's normal to have that many packages
> to be upgraded in 18 months, especially if you enable -backports,
> -updates, and -security.

No. Totally off-the-mark. See above.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0