Quick noob question: Will packages like git-lfs be marked explicitly installed when they originally were an “optional” package? So when they’re listed as orphan, I could remove them?
Little unsure here, because (*cough, cough*) at the beginning of my endeavour, I installed a very few packages using Pamac, and I seem to remember one of those said “needs git-lfs”.
Packages only needed at build time can/will be orphans afterwards, right?
Is there a command that lists installed optional dependencies?
To my knowledge, the optional dependencies, are optionally, intentionally and therefore explicitly installed and marked as such:
Example:
$ pacman -Qi gparted
Installed From : extra
Name : gparted
Version : 1.7.0-1
Description : A Partition Magic clone, frontend to GNU Parted
Architecture : x86_64
URL : https://gparted.org/
Licenses : GPL-2.0-or-later GFDL-1.2-or-later
Groups : None
Provides : None
Depends On : parted gtkmm3
Optional Deps : dosfstools: for FAT16 and FAT32 partitions [installed]
jfsutils: for jfs partitions [installed]
f2fs-tools: for Flash-Friendly File System [installed]
btrfs-progs: for btrfs partitions [installed]
exfatprogs: for exFAT partitions [installed]
ntfs-3g: for ntfs partitions
udftools: for UDF file system support
xfsprogs: for xfs partitions [installed]
nilfs-utils: for nilfs2 support [installed]
polkit: to run gparted from application menu [installed]
gpart: for recovering corrupt partition tables
mtools: utilities to access MS-DOS disks [installed]
xorg-xhost: authorization from wayland
$ pacman -Qi dosfstools
Name : dosfstools
Version : 4.2-5.1
Description : DOS filesystem utilities
Architecture : x86_64
URL : https://github.com/dosfstools/dosfstools
Licenses : GPL-3.0-or-later
Groups : None
Provides : None
Depends On : glibc
Optional Deps : None
Optional For : gparted grub libblockdev-fs udisks2
Conflicts With : None
Replaces : None
Installed Size : 437.22 KiB
Build Date : Sun 25 Aug 2024 03:39:08 PM CEST
Install Date : Sat 14 Dec 2024 01:48:24 PM CET Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
You could remove them without breaking the dependencies for the package they are optional for.
And they won’t be marked orphans if you remove the package for which they were optionally installed.
Thanks! Good you chose gparted so I could follow using the same. So -Qi is another one in my Pacman arsenal now.
For my git-lfs, I’m still unsure, ’cause my pacman -Qi git-lfs tells me
$ LANG=C pacman -Qi git-lfs
Name : git-lfs
Version : 3.6.1-1
Description : Git extension for versioning large files
Architecture : x86_64
URL : https://git-lfs.github.com
Licenses : MIT
Groups : None
Provides : None
Depends On : git
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 12,44 MiB
Packager : Morten Linderud <foxboron@archlinux.org>
Build Date : Mi 19 Feb 2025 20:00:43 CET
Install Date : Mo 05 Mai 2025 20:35:01 CEST
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
but not which package. At the same time, it’s listed as an orphan:
This seems to be telling that it was a “required” dependency of a package, now removed (I guess only by passing -R and not -Rs to pacman) and therefore it is now there all by itself and not required by any other packages.
Here is an excerpt from man pacman which can elucidate further pacman -Qdt and also pacman -Qdtt and the difference between the two:
-d, --deps
Restrict or filter output to packages installed as dependencies. This option can be combined with -t for listing real orphans - packages that were installed as dependencies but are no longer required
by any installed package.
-t, --unrequired
Restrict or filter output to print only packages neither required nor optionally required by any currently installed package. Specify this option twice to include packages which are optionally, but not
directly, required by another package.
Now I’m new, and of course unsure, so I tried this to see what actually would be removed, and the list is much longer. Would you consider it safe to remove all these?
The first pacman command is giving you a list of the “real orphans”, that is
packages neither required nor optionally required by any currently installed packages.
Then you pipe its output into the second pacman which will remove them and their dependencies recursively.
In principle, it should be safe. If you want to take a more conservative approach, you can use the following function in your .bashrc:
rmorph() {
while [[ $(pacman -Qdtq) ]]
do sudo pacman -R $(pacman -Qdtq)
done
}
So you basically remove the real orphans with the -R option until there is none left.
You could also check with pacman -Qqttd to see if there are any one package that may be optionally required by some other package and then if you want to keep it, mark it as explicitly installed.
What I always do if I uninstall something is running the yay command you mentioned, just to be sure, think this would minimize the risk of messing something up.
Cheers, but… well… not yet. Still too anxious, I like to see and check what’ll happen still. And of course I have to memorize all these new pacman and yay commands, so typing them out for a while will be good for me. (Being an old man, see my profile )
In the past, I learned the hard way that to rely too much on automatisms, and becoming lazy, you forget (or never learn) the basics. Thus, if anything really goes wrong, you’re lost. Not so if you’ve learned and understood the underlying basics first.
Agreed. Not necessarily risky, because the Arch core usually has its dependencies sorted out, but it can lead to annoying results with user installed packages and esp. AUR packages.
Sometimes even a package was a dependency but you want to keep it and install it as non-dependency. I happens.
Usually I do something like paru -Qdtq | paru -Qi - and then everything is reviewed manually and uninstalled manually. If you do it every few months and don’t let it accumulate over years that only takes a few minutes.
Yeah now that you mentioned it I was a bit off, I was talking about cached packages, not orphans. I blame it on multi-tasking I have an alias for cleaning up orphans which I run once in a while and then check what it removes.
Removing meta packages can cause serious havoc when removing orphans automatically. Consider the situation where someone removes plasma-meta or base. The system will work fine when removing those packages. However, if they don’t review the package list when removing orphans, bad things can happen.
)