You are not logged in.
Hello:
Weekly updating this morning got me this:
$ apt list --upgradable
Listing... Done
liblzma-dev/stable-security 5.4.1-1 amd64 [upgradable from: 5.4.1-0.2]
liblzma5/stable-security 5.4.1-1 amd64 [upgradable from: 5.4.1-0.2]
liblzma5/stable-security 5.4.1-1 i386 [upgradable from: 5.4.1-0.2]
xz-utils/stable-security 5.4.1-1 amd64 [upgradable from: 5.4.1-0.2]
$
And then this:
$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
liblzma-dev liblzma5 liblzma5:i386 xz-utils
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1151 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.devuan.org/merged daedalus-security/main amd64 liblzma-dev amd64 5.4.1-1 [260 kB]
Get:2 http://deb.devuan.org/merged daedalus-security/main i386 liblzma5 i386 5.4.1-1 [215 kB]
Get:3 http://deb.devuan.org/merged daedalus-security/main amd64 liblzma5 amd64 5.4.1-1 [205 kB]
Get:4 http://deb.devuan.org/merged daedalus-security/main amd64 xz-utils amd64 5.4.1-1 [471 kB]
Fetched 1151 kB in 1s (957 kB/s)
Reading changelogs... Done
(Reading database ... 166981 files and directories currently installed.)
Preparing to unpack ... (files listed)
Unpacking ... (files listed)
Setting up ... (files listed)
--- snip ---
update-alternatives: warning: /etc/alternatives/lzma has been changed (manually or by a script); switching to manual updates only
update-alternatives: warning: forcing reinstallation of alternative ../../usr/bin/xz because link group lzma is broken
update-alternatives: warning: current alternative ../../usr/bin/xz is unknown, switching to /usr/bin/xz for link group lzma
Setting up liblzma-dev:amd64 (5.4.1-1) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for libc-bin (2.36-9+deb12u10) ...
$
Don't have a clear idea as to what is going on.
/etc/alternatives/lzma is a symlink to /us/bin/xz
Please advise.
Best,
A.
Offline
The following packages will be upgraded:
liblzma-dev liblzma5 liblzma5:i386 xz-utils
The link has been renewed....
Offline
Hello:
Thanks for the fast reply.
Much appreciated.
The link has been renewed ...
I was referring to what came afterwards:
--- snip ---
update-alternatives: warning: /etc/alternatives/lzma has been changed (manually or by a script); switching to manual updates only
update-alternatives: warning: forcing reinstallation of alternative ../../usr/bin/xz because link group lzma is broken
update-alternatives: warning: current alternative ../../usr/bin/xz is unknown, switching to /usr/bin/xz for link group lzma
--- snip ---
About the lzma package:
$ apt list | grep -i lzma
lzma-alone/stable 9.22-2.2 amd64
lzma-alone/stable 9.22-2.2 i386
lzma-dev/stable,stable 9.22-2.2 all
lzma/stable 9.22-2.2 amd64
lzma/stable 9.22-2.2 i386
~$
$ aptitude why lzma
i font-manager Suggests file-roller
p file-roller Suggests lzma
$
Seems apt found something amiss in /etc/alternatives/lzma.
ie: something ... has been changed ...
But what | why | who changed it?
That said, do I even need it?
Thanks for your input.
Best,
A.
Offline
Did that update yesterday, but I used Synaptic so didn't see all the output. But it worked fine and nothing is broken in /etc/alternatives.
Could it be because you updated the lzma package(s) for two different arches? That might cause some confusion.
http://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! http://devuan.org/os/donate
Offline
Hello:
... because you updated the lzma package(s) for two different arches?
No idea.
That package is probably in my system since ascii or Jesse and I am now running on Daedalus, to which I arrived through succesive dist-upgrades.
Now ...
Looking at yesterday's timeshift snapshot of /etc/alternatives/lzma I see this:
/etc/alternatives/lzma: symbolic link to ../../usr/bin/xz
In the current version, I see the same thing:
/etc/alternatives/lzma: symbolic link to ../../usr/bin/xz
/usr/bin/xz exist in both cases, same size but different timestamp: 02/12/2023 and 03/04/2025 respectively.
So I don't get the part where apt reports ... /lzma has been changed ... and ... /xz is unknown.
Edit:
I checked to see how update-alternatives read:
$ update-alternatives --get-selections | grep lzma
lzma auto ../../usr/bin/xz
$
So it seems it is on auto and not manual, maybe apt found it had been changed?
Edit_2:
I recalled I had once seen /var/log/alternatives.log.
The printout is rather unreadable but I have tried to split it so as to see what it is all about:
$ cat /var/log/alternatives.log
update-alternatives 2025-04-06 09:30:57: run with
--install /usr/bin/lzma lzma /usr/bin/xz 20
--slave /usr/share/man/man1/lzma.1.gz lzma.1.gz /usr/share/man/man1/xz.1.gz
--slave /usr/bin/unlzma unlzma /usr/bin/unxz
--slave /usr/share/man/man1/unlzma.1.gz unlzma.1.gz /usr/share/man/man1/unxz.1.gz
--slave /usr/bin/lzcat lzcat /usr/bin/xzcat
--slave /usr/share/man/man1/lzcat.1.gz lzcat.1.gz /usr/share/man/man1/xzcat.1.gz
--slave /usr/bin/lzmore lzmore /usr/bin/xzmore
--slave /usr/share/man/man1/lzmore.1.gz lzmore.1.gz /usr/share/man/man1/xzmore.1.gz
--slave /usr/bin/lzless lzless /usr/bin/xzless
--slave /usr/share/man/man1/lzless.1.gz lzless.1.gz /usr/share/man/man1/xzless.1.gz
--slave /usr/bin/lzdiff lzdiff /usr/bin/xzdiff
--slave /usr/share/man/man1/lzdiff.1.gz lzdiff.1.gz /usr/share/man/man1/xzdiff.1.gz
--slave /usr/bin/lzcmp lzcmp /usr/bin/xzcmp
--slave /usr/share/man/man1/lzcmp.1.gz lzcmp.1.gz /usr/share/man/man1/xzcmp.1.gz
--slave /usr/bin/lzgrep lzgrep /usr/bin/xzgrep
--slave /usr/share/man/man1/lzgrep.1.gz lzgrep.1.gz /usr/share/man/man1/xzgrep.1.gz
--slave /usr/bin/lzegrep lzegrep /usr/bin/xzegrep
--slave /usr/share/man/man1/lzegrep.1.gz lzegrep.1.gz /usr/share/man/man1/xzegrep.1.gz
--slave /usr/bin/lzfgrep lzfgrep /usr/bin/xzfgrep
--slave /usr/share/man/man1/lzfgrep.1.gz lzfgrep.1.gz /usr/share/man/man1/xzfgrep.1.gz
update-alternatives 2025-04-06 09:30:57: status of link group /usr/bin/lzma set to manual
update-alternatives 2025-04-06 09:30:57: auto-repair link group lzma
update-alternatives 2025-04-06 09:30:57: status of link group /usr/bin/lzma set to auto
$
Thanks for your input.
Best,
A.
Last edited by Altoid (2025-04-06 20:13:52)
Offline
I think you will find it is because you upgraded the xz-utils package, which is obviously part of xz....
Offline
Hello:
... upgraded the xz-utils package ...
Yes, of course.
My post was about the warnings and whatever reason could have caused them.
Do have a read at the OP.
Best,
A.
Offline
My guess would be that the postinst script of xz is buggy; that for some reason it doesn't recognize that the "alternatives" link for lzma already points correcly.
Maybe the script tries to resolve the link value (the pathname "../../usr/bin/xz") itself rather than resolving the link, and it then resolves that relative to "/" (which would be cwd for the postinst script) rather than relative to "/etc/alternatives" (which is where the link resides). Thus it erroneously claims that the resolved value is missing and different from "/usr/bin/xz"... and yet, when the new "alternatives" link get installed, the "alternatives" subsystem translates the given absolute pathname to one that is relative to where the link is set, so it ends up with the same value that it already had.
Remember that the postinst script doesn't "see" those pathnames the way you see them in the error message.
And I'm sure there are other possible stories that could explain how those peculiar log lines come about.
Offline
Hello:
... postinst script of xz is buggy ...
I see.
... doesn't recognize that the "alternatives" link for lzma already points correcly.
Right.
Makes sense. 8^)
Maybe the script ...
... when the new "alternatives" link get installed ...
... ends up with the same value that it already had.
Thank you for taking the time to figure that out.
I was worried that an unknown something had mucked around the system.
ie: the (manually or by a script) part of the postinst printout.
Not having been me, the only alternative offered was a script.
Not good.
My only intervention (as far as my memory serves me) in update-alternatives was long ago to set the default editor.
For obvious reasons, not vim.
Or emacs. 8^° !
Remember that the postinst script doesn't "see" those pathnames the way you see them in the error message.
Remember?
I did not have a clue, I'll have to learn it first.
Thanks for the heads up.
... sure there are other possible stories that could explain ...
And I'm quite sure that you have worked out the most probable | feasible | likely one.
So I will mark this one as [solved].
As always, thank you very much for your input.
Best,
A.
Last edited by Altoid (2025-04-07 13:28:14)
Offline