How would I manged packaged that are orphaned or no longer exist in the AUR?
Thankfully I didn’t get infected, but I don’t want my system to be vulnerable.
For example I have these packages
-> Packages not in AUR: js115 lib32-libva-vdpau-driver linux-firmware-meta manjaro-firmware progressline-bin python-flask-restful v86d
Some of these are installed by me, but what about the linux-firmware-meta and manjaro-firmware
Your post has been moved to a dedicated topic, as it is potentially a Topic within itself.
The basic procedure is:
1. Check for orphaned packages; make sure that none are packages you actually want to keep:
pacman -Qdtq
2. For any packages you do wish to keep, mark them as explicitly installed, to avoid it being detected as an orphan:
sudo pacman -D --asexplicit <package-name>
3. Finally, remove orphaned packages that are not in use:
sudo pacman -Rns $(pacman -Qdtq)
This basic procedure applies whether packages are installed from the official repositories or via the AUR.
There are further considerations that others may wish to discuss.
Regards.
These are pure Manjaro packages. They were not in the AUR. linux-firmware-meta was replaced by linux-meta. manjaro-firmware could still be in the Manjaro repositories. Please check this. Also lib32-libva-vdpau-driver may not be from the AUR. Generally one should check what the package does and remove it when it is outdated. js115 surely is outdated, maybe you have already js140 installed? And so on… When packages are moved out of the distribution and something from the AUR gets installed (usually there is a dialog showing what packages get installed) one can directly remove them - nothing in your distro (also not the Arch distro) depends on anything from the AUR.
I don’t see a manjaro-firmware, checking a testing and stable installation.
But both have the meta package:
linux-firmware-meta
Which just point to packages:
linux-firmware-amdgpu linux-firmware-atheros linux-firmware-broadcom linux-firmware-cirrus linux-firmware-intel linux-firmware-mediatek linux-firmware-nvidia linux-firmware-other(With some optional deps.)
Packages you installed yourself and which were not installed as dependencies will normally be marked as “explicitly installed” in the database. So even if they are not to be found in the AUR anymore, they wouldn’t necessarily be orphans.
An orphan is a package that was once installed as a dependency, but is no longer a dependency now due to packaging changes.
As for linux-firmware-meta, this was replaced by linux-firmware in the repo, but it’s a meta package, meaning that it doesn’t actually contain anything, but instead it pulls in all of the available linux-firmware-* packages as dependencies.
If you are tight on disk space, then it would be best to find out which of those firmware packages you need, and then mark those as explicitly installed. 
sudo pacman -D --asexplicit <name-of-package-1> <name-of-package-2> <...>
Judging by your profile information, you will most definitely need linux-firmware-intel, most likely also linux-firmware-whence, and possibly — depending on your Ethernet chip — linux-firmware-realtek. But inxi should help you find out what you need.
Once you’ve marked these as explicitly installed, you can then remove linux-firmware, and it will remove the unneeded firmware packages all in one go.
sudo pacman -Rns linux-firmware
As others have said, there is no manjaro-firmware package anymore, although there used to be, a long time ago. You can remove it.
As for removing your real orphans, you can list them with…
pacman -Qdtq
… and remove them with…
sudo pacman -Rns $(pacman -Qdtq)
Just to be clear, “orphan” has an additional meaning when talking about the AUR, especially in the context of the recent AUR incident. That incident involved “orphaned AUR packages”, which refers to AUR packages that no longer have an active maintainer.
Removing all of your unneeded dependencies (while still a good idea) will not protect you if you have a bunch of unmaintained AUR packages explicitly installed.
As of 2026-06-19, the AUR contains 107,618 packages. Of those, there are 13,026 “orphan packages”. The incident has been a good reminder that if you use the AUR, you really need to be aware of what you are doing, and keep on top of things.
Quick question as I’m also trying to clean up after a long while
Why does running
sudo pacman -Rns $(pacman -Qdtq)
produce
checking dependencies...
:: binutils optionally requires debuginfod: for debuginfod server/client functionality
:: caffeine-ng optionally requires xfconf: Support for Xfce presentation mode.
:: cmake optionally requires ninja: for ninja generator
:: cmus optionally requires libao: for AO output plugin support
:: gegl optionally requires graphviz: for gegl-introspect
:: gimp optionally requires cfitsio: for FITS support
...
if the packages that I’m trying to remove are truly orphans (in the sense that they were installed as dependencies)?
Looking at debuginfod, it doesn’t show up in pacman -Qdtq, so it must be that the -s switch in the pacman -Rns is responsible. Should I just omit that switch and run pacman -Rn instead?
No, optional dependencies are not real dependencies if they were installed as explicit or as a dependency of something else.
Sure, but I guess I will be losing some functionality that I’ve come to expect by removing them at once. Perhaps I should just mark them as explicitly installed, though I wish there a way to quickly list optional dependencies as well (without needing to use another utility or pacman helper).
Optional dependencies will not be removed.
Even though they’re listed below the optional dependency notice? E.g.
:: qt5-tools optionally requires clang: for qdoc
:: qt6-tools optionally requires clang: for qdoc and lupdate
:: systemd optionally requires libfido2: unlocking LUKS2 volumes with FIDO2 token
Packages (486) autoconf-archive-1:2024.10.16-4 cfitsio-1:4.6.4-1 clang-22.1.5-1 colm-0.14.7-5 compiler-rt-22.1.5-1 compiler-rt21-21.1.8-1 debuginfod-0.195-1 dnssec-anchors-20250524-1
docbook-xml-4.5-11 docbook-xsl-1.79.2-9 erlang-asn1-28.4.2-1 erlang-core-28.4.2-1 erlang-eldap-28.4.2-1 erlang-inets-28.4.2-1 erlang-mnesia-28.4.2-1
and clang is listed.
If you do not have openshadinglanguage and/or shiboken6 installed, then you don’t need clang.
Sorry, clang was just an example as there are other packages listed as optional dependencies, but now you seem to be suggesting that it would be uninstalled?
Let me repeat: optional dependencies will not be removed (unless they too are orphaned).
Yes, I was just asking if you could confirm that in the example I provided, clang would not be removed. I find that asking a concrete example can help clarify any ambiguities in the interpretation of terminology being used.
The output is not complete, but from what I can make up, clang would be removed.
If you want to know what packages are orphans before actually removing them, just run…
pacman -Qdtq
You don’t need sudo for that. It’ll simply print out the list.
Thanks.
I had checked with -Qdtq before to see the orphans and hoped to remove ONLY those packages listed by using the sudo pacman -Rns $(pacman -Qdtq) command, but (as shown above) ran into these optional dependencies. I think I will either drop the -s switch or mark some of them as explicitly installed as I don’t want to remove them.
That is the smart way to do it.
I’ve only ever pasted a package at a time into pacman -Rns.
And you have took it even further, marking them explicit is something I should probably be doing too. 
Maybe, but there’s the worry that if the dependent package P no longer optionally depends on package X in the future (e.g. if the functionality provided by X was built-in to P), we’ll be stuck with carrying around the now explicitly installed X without ever needing it for anything. And worse, by the time that happens, we might not even remember that X was originally merely an optional dependency!