Old electron packages w/o dependencies blocking system updates

General system Applications
1

Rolling releases such as enOS have huge advantages. However, older electron packages w/o dependencies - probably due to their version numbering scheme - are not being automatically removed.

Thus, the not required packages block system updates usually by endlessly downloading although. Any ideas?

2

Manually remove them using yay

3

When do packages normally get automatically removed?

You should handle your orphans and/or foreign packages.

If you need some sort of pacman hook to ensure you do that then use one.

You mean you have foreign packages that then need manual compilation.

Again it is your responsibility to handle your packages - especially deprecated and/or foreign ones.

If they are orphans and you dont need/want them then remove them.

PS.

I have a thing that will, among other things, prompt orphan removal.

1 Like
5

It takes about 10 seconds here

6

Fine. Any good tutorials around on how to use packman hooks? Thanks

7

Of course theres the Archwiki to start:
https://wiki.archlinux.org/title/Pacman#Hooks

I might also say just look at existing ones.

And there is an AUR package for an orphans hook..

PS.

For listing orphans we might normally use

pacman -Qdt

And we can remove them all with something like

sudo pacman -Rns $(pacman -Qdtq)
2 Likes
8

You can also remove orphans with.

yay -Yc
1 Like
9

It’s a DIY distribution, you can clean up orphans yourself?

10

So called orphans should be checked one by one. PLENTY of times something is marked orphaned when it is not and orphan. Case in point.

~  pacman -Qdt                                                                                             ✔  03:44:58 AM
adobe-source-code-pro-fonts 2.042u+1.062i+1.026vf-2
autoconf-archive 1:2024.10.16-2
dotnet-sdk-6.0 6.0.36.sdk136-2
fish-autopair 1.0.4-2
freealut 1.1.0-10
ftgl 2.4.0-3
gn 0.2223.6e8e0d6d-1
go 2:1.24.3-1
go-tools 4:0.33.0-1
intltool 0.51.0-6
libktorrent 25.04.0-1
libsigc++-3.0 3.6.0-1
nvm 0.40.3-1
python-build 1.2.2-3
python-docutils 1:0.21.2-3
python-installer 0.7.0-10
qgpgme-qt6 1.24.2-1
qt-sudo 2.0.1-1.4
qtermwidget 2.2.0-1
quazip-qt5 1.5-1
rapidjson 1.1.0-6
rebornos-keyring 20231128-1
rebornos-mirrorlist 20241016-1
vulkan-headers 1:1.4.309.0-1
w3m 0.5.3.git20230713_1-1
yarn 1.22.22-2
1 Like
11

Those are still orphans even if you want to keep some of them.
(They were still installed as dependencies of other packages but are now no longer required by any other package.)
Anything otherwise an orphan that you want to keep should be marked as explicitly installed.

sudo pacman -D --asexplicit $PACKAGE

Which will mean those packages are no longer orphans.
This, along with removing ‘real’ orphans, is part of ‘handling’ them.

2 Likes
12

Thanks much appreciated but my point was that one should not run the one command to remove ALL “orphans” without checking what’s in their list first.

1 Like
13

I marked the maclean script as the solution as it solved my problem. Great script which should become part of Arch Linux.

14

That’s automating something that shouldn’t be automated.

1 Like
16

Realized I should make my question a separate thread: Orphan or not (optional deps)

17

Everything is prompted, so theres not really ‘automation gotchyas’ that are relevant.

As to orphans specifically - they are printed before removing even if the user initiates that function. Actually, it ensures all orphans and their would-be unneeded dependencies are printed before confirmation even regardless of any config that might otherwise bypass it (noconfirm, etc).. so it may even be considered safer than some of the regular sudo pacman -Rns $(pacman -Qdtq) in that way.

And, despite what your previous output seems to imply is normal over there, orphans are not something that should usually be existent on your system. As already referenced - if you for whatever reason have any package that was once installed as a dependency but the reason for that dependency no longer exists - an orphan (which also implies incomplete removals and/or neglected regular maintenance) - but you desire to keep that package for some other reason .. then it should be marked as installed explicitly and hence removed from the orphans list.

You run something like a handful of cleaning functions .. when you want to clean things.
The main reason it was made was in in order to contrast cleaning tools with bad habits.
I’m open to any suggestions or criticisms.

1 Like
18

My issue is some on my list will just get reinstalled when certain programs need to be updated. As far as I’m concerned they are not orphans but rather programs that aren’t used directly by the system user but still needed from time to time so shouldn’t be marked as orphans by the system.

19

Then mark them as explicitly installed.

Viola, no longer orphans.

1 Like