Finding Unused Packages in Gentoo

Content:

The Portage packaging system is one of the biggest draws to using the Gentoo Linux distro. The source-based system allows a great degree of flexibility, allowing users to compile packages with the features they need.

It’s not perfect though. It’s possible for your system to become cluttered with unused packages, which could potentially lead to dependency conflicts down the line.

Fortunately, it’s an easy thing to keep on top of, once you know the cause.

The @world File

The Portage @world package set contains a list of the packages that have been manually installed by the user. These files are stored in /var/lib/portage/world.

This is important, as it prevents Portage unmerging packages the user specifically installed, even if there are no reverse-dependencies remaining.

This does mean, however, that packages that are no longer wanted will be retained. That is, unless the user specifically removes them.

When using the basic emerge command, such as

emerge blender

the package will end up being listed in the world file. It’s common to find tutorials that use this basic syntax.

To prevent this, you can install packages using the --oneshot option.

emerge --oneshot blender

--oneshot tells Portage this is a one-off install, and the package shouldn’t be added to the world file.

This shouldn’t be used for every package – there are instances where you want the package added to the world file, to stop its removal from the system.

Finding Unnecessary Entries

To find packages that can be removed, you can run the following script.

#!/bin/bash

world_file='/var/lib/portage/world'
deselect='~/deselect'

while read package ; do
    printf "${package}: "
            emerge_check=$(emerge -p --quiet --depclean $package 2>&1)
            if [[ -n ${emerge_check} ]]; then
                printf "Needs to stay in @world\n"
            else
                printf "Can be deselected\n"
                printf "${package}\n" >> ${deselect}
            fi

done < ${world_file}

This script attempts to remove each package in turn, and checking the result. If the package can be removed, it needs to stay in the @world set. Otherwise, it can be removed. Note that this runs emerge with the -p (pretend) option, so no changes are made.

Packages that can be removed are stored in ~/deselect. Once you’ve got the ~/deselect file, you’ll want to open it, and analyse the entries.

While these packages can be removed from the @world set, you wont necessarily want to remove them all. This would be true, for example, when a manually installed package has a reverse-dependency manually installed later on.

A real world example of this is would be a selected set containing

app-editors/gedit
app-editors/gedit-plugins

The deselect script will identify that app-editors/gedit can be removed. In this case, this is due to having app-editors/gedit-plugins installed, which of course depends on app-editors/gedit.

As app-editors/gedit-plugins is also a user-installed package, there’s a chance I’ll decide to remove this in the future. Doing so would remove the only dependency on app-editors/gedit. If it’s removed from the world file, emerge --depclean would then flag it for removal in this case, and the entry would need to be re-added to prevent this.

That’s not to say that entries that are now reverse-dependencies can’t be removed – just be sure to consider what each package is used for before deciding if keeping the entry is beneficial.

Removing Packages from the Selected Set

Once you’ve got your list of entries to remove, you can then start to remove them from the selected set.

The world file can be edited manually, so it’s possible to remove package atoms from the file using a text editor.

The preferred way, however, is to use emerge, with the --deselect option.

emerge --deselect media-libs/gstreamer

Doing it this way is safer, as it prevents syntax errors or other issues being introduced into the file.

>>> Removing media-libs/gstreamer from "world" favorites file...

You should then see that the entry has been removed. You can verify this by running

cat /var/lib/portage/world | grep "media-libs/gstreamer"

to check if the package name is found in the file. This query should return no result. Be sure to change the package name for the one you’ve removed.

Keeping the File Clean

It’s a good idea to check up on this every so often, as it can help to prevent dependency conflicts and an unnecessarily bloated system down the line.

There are a few steps you can take to reduce the likelihood of having packages to deselect in the future.

When emerging a package, consider the reason you’re installing it. If you’re installing a package to work around a dependency issue, you’re unlikely to need to have it recorded in the selected set.

This is especially true when installing a package-specific update, and it’s the reason the Portage update prompt tells you to run

emerge --oneshot sys-apps/portage

rather than just

emerge sys-apps/portage

Using the --oneshot (or -1) option prevents the package from being added to the selected set.

Get into the habit of using --oneshot where possible. If you later find the package does need to be added to the selected set, you can add it using

emerge --noreplace {package}