Longtime Manjaro users: do you check for orphans?

Support
1

I have started running pamac list -o before and after an update. Each update generated an orphan or two. I reviewed and determined they were not needed on my system and could be removed.

For example:

update 1 - orphans

  1. metis
  2. rest

update 2 - orphans

  1. wayland-protocols

Planning for the future, I can imagine over time, that the number of orphans could grow if not checked. I plan on continuing the review of orphans before and after an install. I have no problem or technical question, thus the Category chosen.

My question, is this something longtime Manjaro users do and is it one or two packages occasionally?

1 Like
2

I also keep mine uninstalled, also checking around update time, or basically whenever I feel like it. And I’ve had no problems, really.

3

I usually check for orphans every now and then. And as you do, I usually evaluate them and then uninstall everything that is not needed.
I sometimes also go through the packages installed and uninstall things I don’t need anymore

4

when i remember or i’m doing other stuff like pruning journals etc I have

alias orph='pacman -Qdtq'

and

alias rmorph='pacman -Rs $(pacman -Qdtq)'

after inspection with pactree if needed.

1 Like
5

You should have made use of the poll feature …

Sure I check for orphaned packages and remove any and all I’m not wanting to keep…
Btw. that’s also mentioned bot the arch wiki

https://wiki.archlinux.org/title/system_maintenance#Check_for_orphans_and_dropped_packages

and the Manjaro wiki:

6

I do not do it each time, but I do clean up orphans and foreign packages once in a while.

Orphans are (normally) useless packages, so it just takes space and bandwidth for nothing. It’s really unusual when something actually useful is marked as orphan; if it happens, you can mark the package as explicitly installed of course.

Foreign packages might be a sign that you have obsolete packages that won’t be updated in the future, so it’s a good idea do deal with them too. Most recent example (as like, right now) is dbus-x11, which is a variant that provides DBUS (which is, hum, a pretty important component for most if not all Manjaro systems out there) that used to be in the official repos, but isn’t there anymore: so you have to take a decision to either move on to the dbus package or to use the AUR, which has a package with the same name. To be honest, with such a core package, I would recommend to avoid AUR and move to dbus provided from the official repositories.

Between orphans and foreign packages, I think the latter is the one that requires most attention.

7

…or you could use a Pacman hook. :wink:

/etc/pacman.d/hooks/orphans.hook:

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

[Action]
Description = Checking for orphaned packages...
When = PostTransaction
Exec = /usr/bin/bash -c "/usr/bin/pacman -Qtd || /usr/bin/echo '=> No orphans found.'"
2 Likes
8

Besides removing occasional packages moved to AUR, i don’t.

9

You also have

yay -Yc

or

paru -c
10

I check almost every update and remove them. Cleaning regularly let you see what has recently become an orphan, if you wait too long you have too much packages to sort and remove or keep (sometimes package become orphan because it was pulled as a dependency of a package, which is no longer a dependency of that package, but you still want to have this now orphaned package so you set it as “explicitly installed”).

It is also a good idea if you enabled the AUR in Pamac, to check after every update for foreign packages, because packages dropped from Manjaro, can be in the AUR with same name, and then Pamac updates the package from AUR, when you probably should have removed it (or not, same as orphans, in some case you may want to keep the package and so having the AUR version now).

2 Likes
11

Weird, I have created a poll in the past, but this time I got an error. Oh well.

An error occurred: You are not allowed to create polls.

This is what I would have created.

### [u]How often do you check for Orpans?[/u]
[poll name=OrphanCheck]
- Once a week
- Once a month
- Once a year
- After every update
- Whenever someone mentions orphan in a new topic
- Never
- What are orphans
[/poll]

***
12

pacman -Qtdq

1 Like
13

Yeah, um, ceph-libs :grimacing:

All great responses. Thank you.

In addiition to @Alfy alias fo orphans, I think I’ll add another for foreign packages pacman -Qm. I can see how that list can grow over time.

I was corrected by a colleague that I shouldn’t say, “the package was moved to the AUR”, but rather “the package was removed from the Manjaro repositories and it just so happened to be in the AUR”.

A while back qpdfview was removed and it seems like quiterss was recently removed. They are both in the AUR. When I first installed, I installed from the AUR: skype, chrome, and notify-send, but the list has grown to include:

gcolor2
gnome-icon-theme
gnome-icon-theme-symbolic
ipw2100-fw
ipw2200-fw
manjaro-firmware
qpdfview
qt5-webkit
quiterss
upd72020x-fw

I’ll probably leave quiterss and qpdfview for the time being, but I recently saw a post that said it’s okay to remove manjaro-firmware. I have been looking for ways to catch these preemptively. Of course the Annoucement, but I was wonder if the gitlab commit list(s) would be helpful. For example, iso-profiles commit list.

I turned the command below into an alias. It covers both Foreign and Orphans. So I don’t have to count, I pipe the output from the pacman commands to tee to display the output on the terminal and pipe to wc.

echo "= AUR Foreign =";pacman -Qm|column -t|tee /dev/tty|wc -l;echo "= Orphan =";pacman -Qdt|column -t|tee /dev/tty|wc -l
15

I have done in the past, and a couple of times I’ve nuked the lot and gotten away with it. Normally I leave them alone though as I’m not all that sure about the consequences of my actions. :grinning:

Oh well. I just nuked all my orphans again. Going to reboot and see if the system is ok. I hope it is.

16

Why wouldn’t it be? Orphans are packages installed as dependencies, which no other package uses anymore…

17

I envy your expertise. I’m a noob. Only been using Linux for 2.5 years and still have much to learn.

18

Everybody is - but the knowledge is right infront of you and you just have to be willing to learn it.
Links to wikis explaining orphans were already given in this thread: just read up if you’re willing to do so.

19

I thought the same, too and uninstalled all orphans until I found some “orphans” still having a function, see example below. Since this time I only uninstall “orphans” I’m 100% sure they are obsolete, which is not easy to evaluate, sometimes. Usually, they don’t take a nameable amount of ressources to spend much time on this decision.

20

Hi. Thanks for your lecture oracle.

I’m actually learning a foreign language at the moment and have been for 2 years. Prior to that I learned sufficient to use linux, so I’m alright jack. To keep you happy I’ll come back and learn more about linux in future.

And as Wollie has just mentioned, I am sure I noticed in the past that some orphans were still relevant to stuff I actually use.

21

Ideally, when I do an update, two things I look for afterwards:

  1. orphans

  2. foreign packages

orphans

I can’t remove all orphans, well I could, they’d just be reinstalled :slight_smile: . Plus I do want to know why things are happening. I have a list of packages that were installed, I believe, mostly because of the AUR packages: autoconf, bison, debugedit, flex, guile, make, patch, pkgconf, squashfs-tools. Most are in “Group=base-devel”.

The last install orphaned 3 more packages (see below). Talked to a colleague and they are of the stance, so what no one is using them, but I’m more of, keep the system “clean” to more readily spot potential problems and prevent problems. I’m think’n it might be easier to stay on top of it when the list is small.

It does take some time to determine why something was installed in the first place and why it isn’t needed any longer. I have a VM created with the same ISO as my host machine. That helps with why it was installed. Then a Internet search helps with why it isn’t needed any longer.

---------------------- show_pacman_orphans ----------------------
===> pamac list -o
lib32-faudio   23.01-1   multilib  285.8 kB
lib32-lcms2    2.14-1    multilib  437.4 kB
libvisual      0.4.0-8   extra     499.5 kB

foreign packages

I am particularly watchful of the packages that have been removed from Manjaro’s repos and are in AUR. It is actually worse, at the moment, if they are in the AUR, because pamac will gladly update ALL of them. I use pacman, but pamac for AUR packages in an automation script.

The last update (jan+feb) added two more packages. I’m up to 12 foreign packages. I started out with 3 that I explicitly installed from the AUR.

Manjaro package change document

I wish I could make heads or tails out of the Manjaro package changes document in the Announcement.
Example: Package changes ( Thu Feb 2 01:37:47 CET 2023 ).

A lot of the document makes sense. The majority of the document contains package name, the current version and updated version, like 0ad.

Where it gets messy is with the “-” in the current and updated version columns, and the base package name still exists.

In the first snippet below, only bsdiff is no longer in the Manjaro repos. So if I want to know, which packages are no longer in the Manjaro repos, it isn’t enough to look for a “-” in the last column, the user has to search the document for the package name to see if it appears some place else.

It’s nice to know what has been added (“-” in first column), but it is more important to know what has been removed and may will negatively impact a user. For example, to know quiterss was removed, a user had to page through a 4062 line document, and on line 2019 there it was :wink:

I have a script now where I only grab the line with a dash in the last column so I can quickly spot removals, but it needs to be refined because a dash in the last column doesn’t necessarily the base package was removed.

#842
0ad                           a26-3               a26-4
glmark2                   2021.12-1                   -
bsdiff                       4.3-12                   -
glmark2                   2021.12-1            2023.01-1
chromium           109.0.5414.119-1                    - 
libreoffice-fresh-af        7.4.5-1                    - 
chromium            109.0.5414.74-1     109.0.5414.119-1
libreoffice-fresh-af        7.4.4-1              7.4.5-1
# 828
dbus-x11                   1.14.4-1                    -
# 798
ceph                      15.2.17-1                    -
# 747
qpdfview                   0.4.18-2                    -
# 822
quiterss                   0.19.4-2                    -