Portage/Help/Maintaining a Gentoo system
There are a few common issues that Gentoo users regularly seek assistance for on #gentoo (webchat) and the forums.
What's normal?
Upgrades are not supposed to be hard. Furthermore, they're not hard for most Gentoo users.
But this doesn't mean people can't experience issues. A fair amount of such cases arise because of bad habits, users lacking the required portage skills, or previously used quick and dirty solutions to problems. This often leads to people avoiding upgrades, and then the problem gets worse.
Procedure
World file hygiene
This is easily the most important point: the system's world file at /var/lib/portage/world should only contain things the user personally wants.
It should not contain (non-exhaustive list):
- libraries, e.g. *-libs/* unless the system explicitly needs them for development
- packages that previously failed to emerge and required running an emerge command again (use emerge --oneshot ... when doing that!)
- most of dev-python/* unless there is an actual need.
- anything the user personally doesn't want/use/need.
Erroneous entries in the world file will lead to blockers when e.g. a library becomes obsolete or replaced, leading to a user having to fix the problem when for most people, it'll be resolved automatically.
Example
sys-fs/e2fsprogs is absorbing sys-libs/e2fsprogs-libs (the details aren't relevant here, but see bug #806875).
If a user has sys-libs/e2fsprogs-libs in their world file, they are telling Portage the system must have it. And Portage will try very, very hard to honour this request, like so:
root #
emerge -p -uvDU @world
[...] [blocks B ] >=sys-fs/e2fsprogs-1.46.4-r51 (">=sys-fs/e2fsprogs-1.46.4-r51" is soft blocking sys-libs/e2fsprogs-libs-1.46.4-r1) [blocks B ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is soft blocking sys-fs/e2fsprogs-1.46.5) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-fs/e2fsprogs-1.46.5:0/0::gentoo, ebuild scheduled for merge) pulled in by >=sys-fs/e2fsprogs-1.27 required by (sys-block/parted-3.4:0/0::gentoo, installed) USE="debug nls readline -device-mapper -verify-sig" ABI_X86="(64)" sys-fs/e2fsprogs required by (app-arch/libarchive-3.5.2:0/13::gentoo, installed) USE="acl bzip2 e2fsprogs iconv lzma xattr zlib -blake2 -expat -lz4 -lzo -nettle -static-libs -zstd" ABI_X86="32 (64) (-x32)" sys-fs/e2fsprogs sys-fs/e2fsprogs required by @system (sys-libs/e2fsprogs-libs-1.46.4-r1:0/0::gentoo, installed) pulled in by sys-libs/e2fsprogs-libs required by @selected sys-libs/e2fsprogs-libs[abi_x86_32(-),abi_x86_64(-)] required by (net-fs/samba-4.15.3:0/0::gentoo, installed) USE="acl client cups pam regedit system-mitkrb5 winbind -addc -ads -ceph -cluster -debug (-dmapi) (-fam) -glusterfs -gpg -iprint -json -ldap -profiling-data -python -quota (-selinux) -snapper -spotlight -syslog (-system-heimdal) -systemd (-test) -zeroconf" ABI_X86="32 (64) (-x32)" PYTHON_SINGLE_TARGET="python3_9 -python3_10 -python3_8" >=sys-libs/e2fsprogs-libs-1.42.9[abi_x86_32(-),abi_x86_64(-)] required by (app-crypt/mit-krb5-1.19.2:0/0::gentoo, installed) USE="keyutils nls pkinit threads -doc -lmdb -openldap (-selinux) -test -xinetd" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="-aes"
Note that the main reason it is pulling in e2fsprogs-libs here is: sys-libs/e2fsprogs-libs required by @selected
. This means the package is in the world file! Portage is trying hard to hold onto it because the user told it to, by previously putting it there.
The output mentions Samba and mit-krb5 but these should be noise as a result of it discounting changing to e2fsprogs due to
-libs
being in world.The solution is to deselect it, which means to remove it from the world file:
root #
emerge --deselect sys-fs/e2fsprogs-libs
Now Portage is no longer being instructed to keep -libs
and should proceed to upgrade.
Depclean regularly
Depcleaning (emerge --ask --depclean) after every world upgrade is essential. This removes unnecessary packages from the system and keeps the dependency graph clean.
Failure to do so may result in:
- older versions of toolchain versions being used unnecessarily (e.g. gcc, binutils)
- packages misbehaving when they detect a package installed which has been removed from the tree
- possibly confusing emerge output on upgrades
- wasted disk space because orphaned packages are being kept installed
If Portage tries to remove packages that are still required, the depcleaning should be canceled and portage instructed to keep the packages:
root #
emerge --ask --noreplace foo
Never unmerge anything
Consider emerge --unmerge banned. Removing packages without --depclean may result in removing something which is needed and will only lead to broken packages and a possibly bricked install.
If the system no longer needs a package, run:
root #
emerge --ask --depclean foo
Portage will ask the user if they wish to remove it only if it is safe to do so (nothing depends on it). It will bail out if it is unsafe.