Testing yum’s autoremove orphaned deps feature

Yesterday I wrote about yum’s new feature which can automatically remove unused dependencies when a package is uninstalled.

Today I got my hands on a suitable build of yum (add the yum-rawhide repo and set clean_requirements_on_remove=1 under [main] in /etc/yum.conf) and I started to test it out on several packages, all of which introduced dependencies. My initial findings? It’s great.

Single package with dependencies
I started with a single package with several dependencies. When I uninstalled the parent package, yum also removed all of its dependencies which were not needed by any other package (i.e. orphaned dependencies).

Let’s look at an example; installing Ekiga which pulls in 5 dependencies.

yum install ekiga
...
Installed:
ekiga.x86_64 0:3.2.7-4.fc14
Dependency Installed:
evolution-data-server.x86_64 0:2.32.0-3.fc14 libgdata.x86_64 0:0.6.4-4.fc14 libgweather.x86_64 0:2.30.3-1.fc14 opal.x86_64 0:3.6.8-1.fc14
ptlib.x86_64 0:2.6.7-1.fc14

OK, so we have Ekiga, and we have 5 dependencies installed. What happens if I remove Ekiga?

yum erase ekiga
...
Removed:
ekiga.x86_64 0:3.2.7-4.fc14
Dependency Removed:
evolution-data-server.x86_64 0:2.32.0-3.fc14 libgdata.x86_64 0:0.6.4-4.fc14 libgweather.x86_64 0:2.30.3-1.fc14 opal.x86_64 0:3.6.8-1.fc14
ptlib.x86_64 0:2.6.7-1.fc14

As I was hoping, yum removed all 5 dependencies along with Ekiga itself. Ta da!

Result: Tick!

Packages with shared dependencies
I then tested two packages which have shared dependencies. What I would expect is that only the dependencies which are unique to the application being removed, are uninstalled. Other shared dependencies remain, because the other program still requires them and is not being removed.

Let’s look at an example; mplayer and vlc. Both require the libcaca library and installing both packages pulled in this library.
VLC needs libcaca:

yum deplist vlc |grep libcaca
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14

And mplayer needs libcaca:

yum deplist mplayer |grep libcaca
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14

When I want to remove mplayer, yum only removes those mplayer dependencies which vlc does not also require, and leaves the rest (including libcaca).


yum erase mplayer
...
Removed:
mplayer.x86_64 0:1.0-0.119.20100703svn.fc14
Dependency Removed:
libvdpau.x86_64 0:0.4.1-1.fc14.1 lzo.x86_64 0:2.03-3.fc12 mplayer-common.x86_64 0:1.0-0.119.20100703svn.fc14

Note that libcaca was not removed, which is the expected result.

Result: Tick!

Removing a package’s dependency
I then tried to remove a dependency, rather than the parent package. I would expect this to remove all parents which required that package, along with their other dependencies.

Let’s look at an example, gnash-plugin. This package pulls in three dependencies (including the actual gnash package).


yum install gnash-plugin
...
Installed:
gnash-plugin.x86_64 1:0.8.8-4.fc14
Dependency Installed:
agg.x86_64 0:2.5-9.fc13 gnash.x86_64 1:0.8.8-4.fc14 gtkglext-libs.x86_64 0:1.2.0-10.fc12

Now, let’s see what happens if I try and remove one of the dependencies.

yum erase agg
...
Removed:
agg.x86_64 0:2.5-9.fc13
Dependency Removed:
gnash.x86_64 1:0.8.8-4.fc14 gnash-plugin.x86_64 1:0.8.8-4.fc14 gtkglext-libs.x86_64 0:1.2.0-10.fc12

As you can see, it correctly removed the parent package, which could no-longer operate without the dependency.

This is such a great advancement over remove-leaves, where last time I tried to remove gnash-plugin (after testing it out, I didn’t want it) yum wanted to remove Firefox!! Fail.

Result: Tick!

Suggestion – clean up existing system
One thing I would like, is the ability to run a system wide cleanup using this code in yum, rather than other rpm orphan tools. Sort-of like an apt-get autoremove. Theoretically, if you’ve always removed any packages on your system with this new feature then you should be right, but it would be nice to sort-of do a clean up at any point (on any system) and get yum to remove any orphaned deps for you. Maybe this already exists.

If you want to clean up existing orphaned dependencies, then package-cleanup is your friend (from yum-utils).

Take a look at all the packages that are orphaned, and make sure it is sane.

package-cleanup --leaves

If you’re happy with the list, you can just remove them all (after you’ve enabled yum’s new autoremove feature, of course!):


yum erase $(package-cleanup --leaves)

You can instantly see the benefit of this new feature – on my machine this command also removes brand new orphaned dependencies, created by the orphans I’m removing! That’s 59 packages in total.

Without this yum feature, it would only remove 36 packages. You would need to run package-cleanup several times, until you’ve really removed all orphaned packages.

Similarly, this works for package-cleanup –orphans but it would be great it this was built into a single yum cleanup type function – one command to do it all.

Summary
From my initial testing, this works really well, although I’ll continue to test it and see how we go. Hopefully this will find its way into Fedora 12, 13, and 14 rather than just 15.

I’m so grateful for this work – it’s something I’ve been crying out for ever since I made the decision to stick with Fedora. Thank you, thank you, thank you!!

13 thoughts on “Testing yum’s autoremove orphaned deps feature

  1. Here’s one more experiment of mine on Fedora 15 Alpha LiveCD (after adding clean_requirements_on_remove=1):

    # yum install banshee
    Installing:
    banshee
    Installing for dependencies:
    banshee-musicbrainz
    gdata-sharp
    giflib
    gio-sharp
    gkeyfile-sharp
    glib2-devel
    gnome-sharp
    gtk-sharp-beans
    gtk-sharp2
    gudev-sharp
    libgdiplus
    libgpod-sharp
    mono-4-preview
    mono-addins
    mono-core
    mono-data
    mono-data-sqlite
    mono-devel
    mono-extras
    mono-mvc
    mono-nunit
    mono-wcf
    mono-web
    mono-winforms
    mono-zeroconf
    monodoc
    ndesk-dbus
    ndesk-dbus-glib
    notify-sharp
    taglib-sharp
    Updating for dependencies:
    glib2

    Transaction Summary
    ==========================
    Install 31 Package(s)
    Upgrade 1 Package(s)

    # yum remove banshee
    Removing:
    banshee
    Removing for dependencies:
    banshee-musicbrainz
    gdata-sharp
    gio-sharp
    gkeyfile-sharp
    gnome-sharp
    gtk-sharp-beans
    gtk-sharp2
    gudev-sharp
    libgpod-sharp
    mono-addins
    mono-zeroconf
    ndesk-dbus
    ndesk-dbus-glib
    notify-sharp
    taglib-sharp

    Transaction Summary
    ==========================
    Remove 16 Package(s)

  2. Hi Andrew,

    Hmm.. that seems strange. Maybe there are some bugs in F15 at the moment? Out of curiosity, what does yum want to remove if you do NOT set clean_requirements_on_remove in yum.conf? Might be worth reporting on Seth’s blog..

    I hope to have a play with F15 soon, but busy with Kororaa 14 at the moment..

    -c

  3. Hi Chris,

    Here’s the answer to your question: Without clean_requirements_on_remove yum will remove only banshee and banshee-musicbrainz. It seems the last one lists banshee as requirement (haven’t checked it but it makes sense).

    Note this is Fedora 15 alpha not synced to latest from rawhide.

    Details follow:

    [root@localhost ~]# yum remove banshee –disableplugin=remove-with-leaves
    Loaded plugins: fastestmirror, keys, langpacks, merge-conf, presto, protectbase, refresh-
    : packagekit, security, versionlock
    Adding en_US to language list
    # cut out some useless info
    =================================================================================================
    Package Arch Version Repository Size
    =================================================================================================
    Removing:
    banshee i686 1.9.5-1.fc15 @fedora 11 M
    Removing for dependencies:
    banshee-musicbrainz i686 1.9.5-1.fc15 @fedora 64 k

    Transaction Summary
    =================================================================================================
    Remove 2 Package(s)

    Installed size: 11 M
    Is this ok [y/N]: n
    Exiting on user Command
    Complete!
    [root@localhost ~]# cat /etc/yum.conf
    [main]
    cachedir=/var/cache/yum/$basearch/$releasever
    keepcache=0
    debuglevel=2
    logfile=/var/log/yum.log
    exactarch=1
    obsoletes=1
    gpgcheck=1
    plugins=1
    installonly_limit=3

  4. Hey Chris,

    A couple of days after posting here I came across a similar bug in redhat’s bugzilla – https://bugzilla.redhat.com/show_bug.cgi?id=653583

    Only difference – the guy has used vlc. The end result turned out to be circular dependencies between the dependencies pulled for vlc. I expect it might be the same thing in my case, though I haven’t verified it. But from what I remember, the dependency packages not removed were all connected to mono.

    Well, I think this concludes the issue for me. RPM/yum is getting better at removing dependencies. But it still lags behind APT as both mine scenario and the one in bugzilla are showing IMHO.

  5. yum erase $(package-cleanup –leaves)

    on my CentOS 5 system wants to uninstall yum along with yum-fastetmirror, yum-priorities, yum-updatesd and yum-utils.

    And thats even though package-cleanup –leaves doesn’t even mention yum but only some audio/video libraries. It’s really amazing how Red Hat got so popular with the worst package management system in town.

  6. Hi,
    I tried this today, I was trying to see if zif works the same, but after I removed mplayer and libcaca did not get removed (actually no package got removed), I removed vlc and again no dependency got removed (libcaca and all other packages), do you know why is that?

Leave a Reply

Your email address will not be published. Required fields are marked *