On Wed, 2025-01-29 at 12:10 +0000, Brad Rogers wrote:
> On Wed, 29 Jan 2025 05:52:34 -0500
> songbird <songb...@anthive.com> wrote:
>
> Hello songbird,
>
> > warning: current package is openjdk-21, but binary format already
> > installed by openjdk-9
>
> I've seen similar messages. Certainly about openjdk, maybe others, I
> can't recall. As everything seems to be working as expected, I don't
> worry about it.
I've seen similar messages, too, and for that same family of packages.
It has been a while so I don't remember which releases were involved.
After having written the rest of this long response, I can remember
battling getting something lik java to work many years ago. Manually
manipulationg JRE/JDK was necessary Internet chatter back then. I have
not had to touch either in over a decade now. They just work things out
on their own. Thank you, Developers!
> {time passes}
>
> I've since taken a look at the relevant package description
> (binfmt-support) and, IMO, that message shouldn't even be a warning,
> but
> simply a notification.
In my case these days, I have two things I would do to take a poke at
this in hopes something obvious presents itself:
$ apt-cache policy openjdk-9
I might even try the much busier "apt-cache policy openjdk-*" to see if
anything else is lingering. My setup throws an "unable to locate
package" advisement for 9.
The second thing that I would try is:
$ apt-get autoremove -s openjdk-9
Rationale there is to see if it's still an active dependency that tries
to also remove other important packages or if it's just an oddly
dangling residual. My current JRE 21 wanted to take some pieces of
libreoffice with it when I "-s" symbolically autoemoved my installed JRE
package.
I have an oddly dangling package that YOU just helped me FINALLY solve:
linux-image/linux-headers and friends for 6.9.10 also on a Trixie
partition that's a couple years old.
6.9.10 is not being found for removal by e.g. a generic "apt-get
autoremove". Kernel 6.12.10 is the latest installed on that Debian
partition after multiple upgrades over time. Kernels are now properly
autoremoving as expected when appropriate.
The point for sharing that is that on rare occasion, outdated packages
do get locked in. Mine is an outdated Linux kernel.
A quick Internet search found openjdk-9 being dated circa 2017:
https://openjdk.org/projects/jdk9/
An afterthought while proofreadiing this email: What does something like
apt-mark say about its status? THIS is what helped finally solve my own
outdated Linux kernel dangler.
For my openjdk-21-jre-headless, I just ran the following queries that
provided appropriate results:
$ apt-mark showhold openjdk-21-jre-headless
$ apt-mark showinstall openjdk-21-jre-headless
$ apt-mark showauto openjdk-21-jre-headless
$ apt-mark showmanual openjdk-21-jre-headless
Showhold will tell if a system admin's decision (yours) was made ages
ago to keep the package from being purged by e.g. apt-get during regular
upgrades.
Showinstall will just advise if the package is being acknowledged as
installed.
Showauto/showmanual is what solved my own problem. Those provide a clue
about how the package ever became present. If showmanual is a positive
hit, that would be how an outdated package remained on a system beyond
its release's expiration date.
In my case, I probably had installation problems to the level that I
performed maybe a "dpkg -i" install. The system's rationale on auto vs
manual gets iffy there (for me) because an "apt-get install" of the
kernel is marked as auto.
Litmus test was to run "apt-mark showmanual gimp" which shows as a
manual install when gimp's manually installed the same way as my first
kernels' "apt-get install linux-image-amd64" during new debootstraps.
Whatever, it works for me so that both the kernel and gimp upgrade
and/or autoremove as expected.
Again regarding a sysadmin's choice of auto versus manual installations
of certain packages: The package management program (apt, apt-get, etc)
is respecting that the system administrator made an executive decision
to specifically install that specific package for reasons beyond the
scope of e.g. apt's conditioned rationale for its own automatic actions.
Hope this helps somehow. It just made my own head hurt a litte, lol.
PS Second afterthought: If openjdk-9 is no longer needed and is, in
fact, being reported as a manual install by apt-mark, "apt-mark auto
openjdk-9" MIGHT help depending on how the system is recognizing that
old package. If this was my glitch, I'd try that command just to see how
Trixie handles that outdated package. My curiosity is about testing
Trixie's recognition of that old package.
I use that command all the time because I accidentally install upgrades
twice when I'm working through those times where a couple hundred
packges need upgraded. That command instantly fixes that dreaded message
that says my long list of packages was already installed and has now
been marked as manual. GACK.
PPS On a related command note, "apt-mark showmanual" is my best friend
during debootstraps. It throws a list of the packages that have been
cherry picked and manually installed over time.
PPPS man apt-mark...........
Cindy :)
--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed! *
