Dev1 Galaxy Forum / [SOLVED] Progressively upgraded Daedalus / dead/dangling links

Re: [SOLVED] Progressively upgraded Daedalus / dead/dangling links

dummy@example.com (Altoid) — Tue, 02 Jul 2024 11:57:32 +0000

Hello:

@GlennW

... may find a manual (diy) approach more reliable,

It sometimes is.
ie: you can see what is being done because you are doing it.
But I agree, symlinks seems to be reliable enough.

@aluma

... garbage from your previous installations.

Yes, the Beowulf -> Chimaera -> Daedalus was not exactly seamless but everything has been falling in place.
So no complaints, just a few loose ends that turn up as I go along.

~$ sudo symlinks -csrv / | grep dangling
~$

No more dangling links.
Thanks to both for your input.

Best,

Re: [SOLVED] Progressively upgraded Daedalus / dead/dangling links

dummy@example.com (aluma) — Tue, 02 Jul 2024 09:16:49 +0000

@Altoid
I think this is garbage from your previous installations. On my Daedalus there were only two lines

dangling: /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf -> ../../../../share/qtchooser/qt5-x86_64-linux-gnu.conf
dangling: /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN

Removed by adding the "d" key to the symlinks command, this is the output in a new session after the command in the bottom line.

root@devuan:/# symlinks -csrv / | grep dangling
dangling: /root/.trinity/tmp-devuan -> ../../tmp/tde-root
dangling: /root/.trinity/socket-devuan -> ../../tmp/tdesocket-root
root@devuan:/# symlinks -csrvd / | grep dangling

Re: [SOLVED] Progressively upgraded Daedalus / dead/dangling links

dummy@example.com (GlennW) — Mon, 01 Jul 2024 22:20:32 +0000

The symlinks program is effective.

I have been using symlinks to clean up for a long, long time and can't remember it failing or causing any other problems.

You may find a manual (diy) approach more reliable, but (you only have a very short list there) you might find that even if you rename the dangling links to correct them or to make them safely redudndant the proper links already exist or it'll be so catastophic you'll be reistalling anyway.

Trust me, I am not a doctor.

[SOLVED] Progressively upgraded Daedalus / dead/dangling links

dummy@example.com (Altoid) — Mon, 01 Jul 2024 13:28:06 +0000

Hello:

Thanks to a tip from GlennW, I discovered my Devuan Daedalus installation has quite a few dead / dangling links.

Running the symlink utility I got this result:

~$ sudo symlinks -csrv / | grep dangling
--- snip --- 
dangling: /usr/bin/hsdb -> /etc/alternatives/hsdb
dangling: /usr/bin/clhsdb -> /etc/alternatives/clhsdb
dangling: /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf -> ../../../../share/qtchooser/qt5-x86_64-linux-gnu.conf
dangling: /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN
dangling: /etc/systemd/system/reboot.target.wants/hwclock-save.service -> /lib/systemd/system/hwclock-save.service
dangling: /etc/systemd/system/getty.target.wants/getty@tty1.service -> /lib/systemd/system/getty@.service
dangling: /etc/systemd/system/multi-user.target.wants/smartd.service -> /lib/systemd/system/smartd.service
dangling: /etc/systemd/system/multi-user.target.wants/remote-fs.target -> /lib/systemd/system/remote-fs.target
dangling: /etc/systemd/system/timers.target.wants/apt-daily.timer -> /lib/systemd/system/apt-daily.timer
dangling: /etc/systemd/system/timers.target.wants/apt-daily-upgrade.timer -> /lib/systemd/system/apt-daily-upgrade.timer
dangling: /etc/systemd/system/poweroff.target.wants/hwclock-save.service -> /lib/systemd/system/hwclock-save.service
dangling: /etc/systemd/system/halt.target.wants/hwclock-save.service -> /lib/systemd/system/hwclock-save.service
dangling: /etc/alternatives/hsdb -> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/hsdb
dangling: /etc/alternatives/clhsdb -> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb
dangling: /tmp/LibreWolfBackgroundTask-2EAE590C059AE8C2-removeDirectory/lock -> 127.0.0.1:+13532
dangling: /root/.config/pulse/26a708d3d7dc6778fc6ff9f55921b024-runtime -> /tmp/pulse-PKdhtXMmr18n
~$

I had come across the first two when I had a working fslint in my Beowulf installation but it became a casualty of the end of python2.x.
As a result, it was abandoned by the maintainer.

I have an innate dislike for untidiness of this sort in a working system, surpassed only by the 'won't fix' attitude some* maintainers have when getting a bug report.

To me it is like dirt being swept under a rug.
It eventually forms a lump and becomes something you can trip over and cause damage.

But I digress ...

The question is:
What is/would be the best way to check that these dangling links can be effectively removed?
ie: without screwing up something in the process.

It does not matter if it takes time or has to be done manually: it has to be as foolproof as possible.

Thanks in advance,

* one very notable exception (that I know of) being the people behind BackInTime who actually chased and fixed a Heisenbug.
Kudos to them.