Longtime Manjaro users: do you check for orphans?

You also have

yay -Yc


paru -c

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).


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


pacman -Qtdq

1 Like

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:


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

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.

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

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

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.

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.

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.

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

  1. orphans

  2. foreign packages


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.

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                    -

Keep in mind that the overlay packages section may show packages that were removed in favor of the synced package. In your list, glmark2 was just imported from the AUR to the Arch community repo so we dropped our overlay. chromium and libreoffice-fresh packages were fast-tracked previously.

How often do you check for orphan and foreign packages?

  • After every update automated (hook or script)
  • After every update manually
  • Once a month
  • Once a year
  • When I think about it
  • Never

0 voters

When you come across orphan packages, what do you do?

  • Leave them alone
  • Just remove them
  • Remove after doing some research
  • Mark them --asexplicit, so they don’t appear in the list
  • Don’t know enough to take action

0 voters

When you come across foreign packages, what do you do?

  • Update IgnorePkg in /etc/pacman.conf and use as-is until it dies
  • Look for alternative software in Manjaro’s repositories to fill the need
  • Use the AUR version of the package
  • If in the AUR, vote, and hope the package is promoted
  • Don’t need the software anyway, so remove it
  • Need something to fill the void, but removed it

0 voters

I’m not 100% confident on the whole overlay business, but I’m getting there :slight_smile:

Where would I report a feature request for the “package changes” report that appears in the announcements?

Content moved to: Feature request for the "package changes" report that appears in the announcements

At this time, I sort of think of orphans, foreign packages and software removed as one project after an update.

:point_right: #site-feedback:feature-request

With the lastest Stable Update, “Known issues and solutions”, “Switch to the base-devel meta package requires manual intervention” (pacman -S base-devel) reduced orphans from 15 to 7. Which makes sense given a number of the packages were the result of a limited, but needed, AUR packages.

Executing pacman -S -g 'base-devel' | wc -l resulted in a change of 27 to 18

Typically I use the one-liner as outlined in the Arch Wiki as root:

pacman -Qtdq | pacman -Rns -

and yes, there are many orphans usually of the development packages used by AUR packages. But I don’t mind cleaning them up, because if I need another AUR package, they get reinstalled as dependecies.

The only thing I am not sure sure about are flatpaks and how to prune them. Is it even necessary?

I’ll cleanup flatpaks from time to time using the following:

flatpak uninstall --unused

This only uninstalls runtimes that have been left over from removed apps and are no longer being used by others. You shouldn’t need to do this as an update should clean it up, But it has come in handy.

1 Like

In case you guys want some inspiration or just a tool to automate maintenance, this script should cover most use cases.

1 Like