Something may have been installed as a dependancy which you may want to keep for instance and you would want to mark it as explicit prior to removal for instance. Also, in the shadow of Arch, as Endeavour is built on, you are the master of your own system. Maybe you want some of those packages. Maybe not, it’s up to you.
For more information on changing from asdeps to asexplicit check out the pacman man page at:
Whatever helps you make that choice. There’s more than one way to do the right thing (usually, at least, this is a guideline as sometimes there is only one way).
I made this as a starting point for folks who don’t know other ways.
thank you for the response. how do you, personally, go about deciding which -Rns orphans to get rid of? thank you, I’m learnng a lot.
I know you wrote this as a starting point, so I will hold up my end and research more on what is the smart way to make sure you can remove an orphan. thanks.
Recursively uninstalling orphans can be overly aggressive as packages which are optional dependencies of other packages can be removed. In your case, I would be hesitant too; that package list looks like a lot.
Consider removing the -s (so the action is not recursive), and just run the command two or three times in a row if needed (until no more packages are identified as orphans).
If you are interested, this less aggressive approach to removing orphans was discussed at length in this thread:
ok I can dig this: the conversation in the link is the very thing I’m asking.
And without reading it all yet I can tell there is a lot of truth to how one uses the three arguments (Rns) together and separately. that makes it clearer. An aggressive action like Rns together seems guaranteed to fubar something because for my limited knowledge I wouldn’t know what’s connected to what since -Si seems misleading (or I don’t know how to interpret.)
I copied and pasted the fine commands in the original post, but but the how-and-why context for remove orphans is the last missing command in my list. Am reading now. Thank you.
Unfortunately, in Arch world, the term “orphan” or “orphaned package” has at least two very different meanings.
For installed packages on one’s system, the term is colloquially used instead of the more accurate term “unneeded dependency”. These are packages that were installed as a dependency for another package, and in the meantime that other package was either removed (uninstalled from the system) or updated to not need this dependency. Typically, it is safe to remove them, unless you want to keep them (maybe they are optional dependencies for something else, or just useful on their own), in which case you may want to update the install reason to “explicitly installed”, so that they are no longer orphans.
For AUR packages, the term “orphan” means something completely different. It’s a package (or, better put, a recipe to build a package) that has been abandoned by its maintainer and currently has no maintainer. These are especially dangerous and should never be automatically updated without checking the changes. This is because literally anyone, including people with malicious intentions, can adopt an orphaned AUR package. If it is a popular package, it’s an attractive target for evildoers who wish to spread malware.
Now, since AUR packages can have other AUR packages as dependencies, it is possible for an AUR package to be an orphan in both of these senses: as an unneeded dependency, and as a package without a maintainer.
Such overloaded terminology can be confusing – I remember being confused about it myself when I first started using Manjaro…
What’s not in this guide is yay -Sc. (Have I read all 107 posts? I think so but can’t swear to it).
After months of using pacman -Sc I tried the yay version just for the helluvit.
Results: freed up significant room, I had a lot of debris.
and thank you for getting back.
Let me read your links. I’ve–weekly–done the pacman -Sc and have never looked back/no repercussions.
But yay? I can only imagine its AUR stuff I’ve compiled then removed, or built and re-updated etc. I did remove it all last night, let me read to see why that’s a bad idea…I always get smarter after the fact, never before
Reason being it’s not included is that you SHOULD NOT be using the AUR without knowing about it or why or how it works.
Here’s what Arch says about it:
That being said, the AUR isn’t supported directly by Arch, and therefore, I could not recommend trying to support it here either. If someone is asking about clearing it’s cache, then they are already in over their head.
Admittedly, we as a distro do include and ship yay in a base install. If I had it my way, and in my very humble opinion, yay would NOT be included in the normal installation process. I think anyone who wants to use it, should know how to build at least one package properly prior to using the entirety of the AUR. But so far, my opinion about leaving it out has not been agreed upon.
tl:dr - AUR isn’t supported by Arch, and neither will we (or at least me in my guide)
Edit: actually, they may even be over looked by pacman. I can’t remember now that I’m thinking about it. AUR packages may be managed by pacman -Sc. Maybe someone else can chime in. It’s been some time since I’ve tried this.
@fbodymechanic Glad I ran across this. Read through the initial post and it all just made sense. So, I followed the steps. All went well. Thanks so much for sharing. Bookmarked for future reference.
Indeed. One of the first things I bookmarked from this forum. Much of that is common sense to experienced Arch (or Arch-based) users. But for intermediate users (like myself) and for newbies, that is a valuable post.
allow to KILL ALL ORPHANS all at once!
