On 2023-03-26 17:37, Cindy Sue Causey wrote:
On 3/26/23, Jesper Dybdal <jd-debian-u...@dybdal.dk> wrote:
Packages with upgradable origin but kept back:
Debian stable:
guile-2.2-libs w3m
DISCLAIMER: The subject line indicates a distribution upgrade, but it
looks like your sources.list is only Bullseye. My response is based on
a stabilized single
It was a clean Buster with a few backports, and I upgraded it following
the instructions in the Bullseye release notes. Basically:
* apt update
* apt upgrade --without-new-pkgs
* apt full-upgrade
Hi.. There's a long response attached below, but first I'm wondering
if this is an appropriate instance for using:
apt-get dist-upgrade
I just searched the standing emails and didn't see it mentioned yet.
It comes to mind to ask because of the subject line here.
The rest of what I wrote.........
If this had been my upgrade, my now several years long method of
attack is to try:
apt-get upgrade guile-2.2-libs
I changed to that method after seeing it mentioned on Debian-User.
Prior to that, I *used to* do "apt-get install <held-package-name>".
Don't do that. That messes with how apt labels packages as "manual"
and "auto" with respect to how they came to be installed.
The following might work if one is nervous about the outcome, but I
don't have a way to test it to prove as fact right now:
apt-get upgrade -s guile-2.2-libs
Doing that gives:
The following packages will be REMOVED:
libgc1c2
The following NEW packages will be installed:
libgc1
The following packages will be upgraded:
guile-2.2-libs libdatetime-timezone-perl tzdata w3m
I think I will either do that or try to remove them
If I try "apt-get -s upgrade" (i.e., without the package name) it says:
The following packages have been kept back:
guile-2.2-libs w3m
The following packages will be upgraded:
libdatetime-timezone-perl tzdata
So I'm beginning to suspect that the libgc1/libgc1gc2 packages have
something to do with it.
Thanks a lot! - also for the more general information quoted below.
Jesper
That's a simulated upgrade that theoretically shows most of what will
occur if the user decides to follow through.
Every time I've ever chosen to upgrade a package that's been held, the
situation has been one or more of the following:
1) A package's numbering sequence has been raised a significant step
2) One or more new packages will be installed as part of the newest upgrade
3) One or more old packages will be removed as part of the newest upgrade.
Step 1 usually runs in tandem with Step 3. Not always, though. Python2
and Python3 come to mind as an exception. They can both be installed
together in cases of dire necessity. I'm not totally comfortable
highlighting Python as an example, but I am seeing them called
"different versions of" instead of "different programs based on"
Python out on the Net.
The kernel is an example of where holds occur on regular occasion. The
kernel affects almost everything else. Developers keeping it on hold
helps system administrators manually address its upgrade. That gives
sysadmins the opportunity to review the kernel's changelog and verify
that their production machines will continue to work as flawlessly as
possible after each upgrade.
For my usage of Sid, I would look at:
https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.20+1_changelog
That was found by following a path starting at:
https://packages.debian.org/search?keywords=linux-image-amd64
Cindy :)
Side Note: I say "kernel affects _almost_ everything else" because
installation of the kernel is not the first step in the debootstrap
process. The kernel's installation occurs a few steps in after e.g.
the time settings, HOSTNAME, keyboard configuration, apt's
personalized repositories, limited sysadmin type package
installations, and /dev's base ("generic") devices have been
established. The steps to perform those actions operate successfully
with no kernel on board yet.
--
Jesper Dybdal
https://www.dybdal.dk
