Tag Archive for 'fedora'

Page 2 of 6

On becoming a Fedora maintainer

Recently, Rahul Sandaram (Fedora dev and creator of the Omega Fedora Remix) offered to sponsor me to become a Fedora maintainer, which I accepted. A day or so later I pushed my first updates into Fedora for deja-dup – the package I now co-maintain while I learn the ropes.

Previously, one would become a maintainer by first submitting a new package and thereby overtime demonstrating an understanding of the Fedora packaging process and guidelines. However recently a new system was approved whereby one could become a co-maintainer of an existing package, instead. This requires being sponsored by an existing maintainer, which Rahul was for me.

It’s quite a big task, but Rahul was very helpful and patient while I learned about the process. There is a lot of information on the Fedora Wiki but I found there wasn’t really a single place which provided a nice overview, broke down each section in detail, and then explained all the steps required. So that (along with my cautious nature) meant it took a dozen or so clarifying emails back and forth between Rahul and myself.

When I got my first understanding and taste of the system though, I’ve gotta say, I was quite impressed. The scale of the system and architecture and how it all works is amazing. The build files (RPM spec files) of all the packages in Fedora are kept under their own git repository. Hooks into this git system and special build tools manage the whole process. All in all, this automation makes it quite seamless.

So after reading and doing everything Rahul sent to me, I started on my journey.

There are two development systems to update now – rawhide (development tree) and F15 (the upcoming version). I wanted to update both of these to the latest upstream version, 17.90. I also wanted to update the stable Fedora 14 package to an upstream bug-fix release, version 16.1.1.

Cloning deja-dup from the git repo put me in the rawhide branch by default. I updated the spec file – increasing the version, adding python-cloudfiles as a new dependency, and putting in a detailed changelog. I then committed that to my local git repo with a comment linking to upstream. I then pulled those changes from rawhide into the f15 branch and updated f14.

commit bb1a5daa9feea74640fd84a0174e74e4e83ad34b
Author: Christopher Smart
Date: Sat Mar 5 21:23:07 2011 +1100
     Updated to upstream bugfix version 16.1.1.
     "This release fixes a bug in the just-released 16.1 that caused help
     documentation to not be translated."

Next I needed to test these packages, so I built a source RPM from the spec for each version. I discovered that one can either do a mock build on their local machine, or use Koji to do a scratch build on Fedora’s online build system. I did both, which worked well.

Using Koji meant I needed to first push my changes back to Fedora first though (or so I thought), so I was hesitant to do it without first checking with Rahul. This was the sort of thing that was emailed back and forth – I didn’t fully understand the system and didn’t want to break anything! For example, in order to test my F14 update I had to push back to the git repo – but what if I made a mistake in the process? Would my build on Koji push this broken package onto everyone’s system?

Fortunately, no. Once all the updating of the spec file and building is complete, the maintainer has to formally submit it into the update process before anything will happen. In addition, each package must then pass approval by other maintainers before it is approved and pushed out. You can see why it took some back and forth between Rahul and myself – I wanted to be sure I wasn’t going to do some damage :-)

Along the way I discovered new automated ways of doing things, such as validating a spec file, automatically downloading the source tarball to update the spec file, then uploading it to the Fedora build system.

In the end though, I think that I have a pretty good grasp of the overall process and am quite excited by the prospect of becoming a Fedora maintainer. I’m hoping that deja-dup comes out with a new update soon, so that I can do another update!

I’m still a little hesitant to go and change things – I don’t want to do the wrong thing or step on anyone’s toes. I did however create my own page on the Fedora Wiki, complete with a hackergotchi, of course.

So once again, thanks to Rahul for his patience and guidance :-)

Kororaa 14 (Nemo) Beta3 released

Kororaa 14 (Nemo) Beta3 has been released for download, in 32 and 64 bit with KDE and GNOME.

It is recommended to back up your data and perform a fresh install as this fixes several important bugs.

New features:

  • Latest packages including updated kernel, latest KDE, and GNOME
  • Added Kdenlive video editor to KDE
  • Added HandBrake ripper
  • Set previews for various file types in Dolphin (KDE)
  • Added Fedora printer configuration tool to KDE
  • Added deja-dup backup tool
  • Replaced PiTiVi with OpenShot in GNOME
  • Fixed Elementary theme issue under Nautilus in GNOME
  • PolicyKit tweaks for printing, should be seamless (please test!)

Bug fixes:

  • Lots :-)
  • Problem with new users being added to wheel group
  • Dropped Livna repository due to unreliability
  • Fixed bugs in add-removes-extras script

We’d love to hear your feedback on the forums, so download it today! :-)


Kororaa Beta2 released – new GNOME version, KSplice, LibreOffice

Kororaa 14 (Nemo) Beta2 has been released for download.

This release includes several fixes, updates to all your favourite applications, as well as the following major changes:

Download it today! :-)


Why Kororaa is (now) derived from Fedora

You might be wondering why I chose to derive Kororaa from Fedora. Perhaps you have used Fedora in the past yourself and been burnt, or perhaps (like I used to) you can’t stand Yum, Fedora’s package manager. Perhaps you even hate RPMs?

Well let me say, I understand!

Let me also say, that I think you should give Fedora another chance (like I did), or at least continue reading this post :-)

All distros are different and they have different goals. However, I’m drawn to Fedora for several reasons including the fact that at its heart, Fedora is about building a community of contributors, not just consumers.

Relationship with Red Hat
Fedora is a community operating system, whose major commercial sponsor is Red Hat. Many Red Hat engineers work on free software projects (see Upstream below) and Fedora provides a platform to push those changes to a large audience. While there is a small team of Red Hat engineers dedicated to working on Fedora, it remains primarily a community driven project.

Fedora has a great set of values, which embody the very heart of the community; Freedom, Friends, Features, First. A central goal for Fedora is advancing free software and content freedom.

In particular, I admire Fedora’s strong support of freedom. This means that they do not ship (nor support) proprietary software, but naturally prefer (and create where necessary) free software alternatives. For example, instead of building tools to help install NVIDIA drivers Fedora invested in Nouveau, the free 3D driver for NVIDIA cards. This not only keeps Fedora free to re-distribute, but it benefits the whole Linux community. That’s extremely admirable, in my opinion.

That’s not to say that you can’t get the NVIDIA drivers, or other proprietary software for your system. Various third party repositories, such as RPMFusion, exist for this very purpose (and of course, Kororaa configures all this for you out of the box!).

Package Management
Yum (and RPM) have made leaps and bounds over the last few years and I actually quite enjoy using it now (and it’s quite fast!). Having said that, most package commands are run through PackageKit these days. As for RPMs themselves, they’re just a binary package format like Debs – it’s the package manager that makes the difference.

Download an RPM from the net and you can install it with Yum (or via the GUI using PackageKit), which will automatically pull in any dependencies for you. You rarely use the rpm command, like in Debian and Ubuntu you rarely use dpkg.

Security updates
Yum has a very handy feature, namely the ability to list and install only security related updates. It’s as simple as:
yum --security update

If that wasn’t useful enough, you can also install an update which fixes a specific bug. You can get a list of all updates and their bugzilla numbers with:
yum list-sec bugzillas

Now, once you have the update to fix that specific bug, you can install it using the bugzilla number from the list above.
yum --bz 650995 update

You can also combine the security option with bugzilla:
yum --security list-sec bugzillas

How powerful is that?!

Fedora also has a wonderful addition, called groups. After some educational software, office programs, or support for your language? It’s easy, just install the group you need, like so:
yum groupinstall "Educational Software"

If you’re a developer, getting started with Fedora is easy. Just install the development group you need, such as GNOME, KDE, Java, Kernel, Perl, or even the Web.
yum groupinstall "Development Tools"

There are almost 200 groups, ready to make your life easier!

Community repos
Fedora also has several contributor repositories available for end users. This is sort-of similar to Ubuntu’s PPA (Personal Package Archive). However, Fedora often provides updates for major packages, so you don’t actually need to add a separate repository to get the latest version of things like KDE.

Apt fall-back
If that’s still not enough, you can also install Debian’s Apt package manager and other graphical front-ends like Synaptic in Fedora!

Similar to other non-rolling release distros, Fedora generally only applies bug fixes to a stable release, rather than introducing new features with later versions.

Having said that, Fedora does often provide major updates to some specific programs, including KDE. In general, I have found that often packages like Firefox, OpenOffice.org and the Linux kernel itself get major updates. So, with Fedora you are not left behind quite as much, nor having to add repositories for unofficial builds. I like that :-)

With every new release, Fedora is often leading the charge to implement new free software technologies. In fact, Fedora’s primary sponsor Red Hat is responsible for some of the greatest desktop enhancements ever, including AIGLX (Accelerated Indirect GLX), D-Bus, DeviceKit, HAL, NetworkManager, Ogg Theora, and PolicyKit. Even the Wayland display server (which Ubuntu has announced they are moving to) was started by Kristian Høgsberg when he was working for Red Hat (he’s now at Intel).

Not to mention that out of all the vendors, Red Hat contributes the most to the Linux kernel and to X.Org. Red Hat is also the biggest contributor to GNOME (including GNOME Shell) and they also provides infrastructure, hosting and bandwidth for the project.


Fedora works as closely to upstream as possible. They don’t go off on their own tangent with disregard for upstream projects. If they want to have something changed, they work with upstream to create fixes and introduce new features.

Take the Chromium web browser for example. It’s not included in Fedora for several reasons, but Fedora people are working with Google to fix these issues, so that it can be included nicely. By doing this, other distros will benefit!

Having said that, there are Chromuim builds available too. Just add the repository and away you go!

I used to wonder at the usefulness of SELinux (Security Enhanced Linux). Afterall, this is Linux right? It’s secure enough.

That might be true, but SELinux is still extremely useful (and even Debian is now implementing SELinux).

SELinux works by protecting your system, even if there is an exploit available in an application which gives users root access. Take Apache for example. In a non-SELinux enabled system, if a user gains root through an exploit in Apache they will have full access to your machine. Not so with SELinux. Even if someone gains root access, there are rules around what Apache can and can’t do. For example, these might be restricting it to only read the directory which holds websites. Your system is compromised, but the damage is limited.

SELinux is not just useful for servers. It’s also valuable to your desktop system, especially if you use Adobe’s proprietary flash player (which is known to have lots of security holes). When Fedora first implemented SELinux, there were lots of issues because it would block the system from doing what was considered normal tasks. These growing pains are now over, and SELinux rarely gets in the way. Even if it does, the graphical tool which pops up will tell you how to change that particular behaviour (if you really want to).

Of course, at the end of the day you can still turn SELinux off (or just to warning mode). Kororaa leaves it enabled, as it’s a great way to add extra security to your system, especially as a major part of our lives are now lived on the Internet.

Fedora comes with lots of handy graphical tools to help you manage your system, including

  • firewall
  • language settings
  • network shares
  • services
  • users
  • web server

And many more..

In the last few years I’ve been solely using Fedora and I have been super impressed with its reliability. Things just work, as you would expect them to. No weirdness. Even though Fedora provides major updates to many packages, it’s still more reliable than other popular distributions I’ve used. Perhaps this is due to sticking close to upstream.

Fedora is truly a great, free operating system. Its core principles are ones that I fully support, but which I recognise might restrict or turn off some users. This is why I chose to re-launch Kororaa as I have, so that users don’t give up on Fedora (and Linux) before they have a chance to love it. I see great potential in Fedora, and great benefit to those who are using it.

Thanks to their wonderful build tools like livecd-creator, I am able to build a powerful operating system that includes all those tweaks and extras that users want.

Now, why not give Kororaa a shot? :-)

Kororaa Lite (KDE) beta released

Kororaa Lite (KDE) has been released and is now available for download in 32 and 64 bit.

Kororaa Lite 14 (Nemo) desktop

Kororaa Lite is a minimal KDE based system which provides a smaller footprint for users to then install the programs they want. It disables various services and cuts out some hefty KDE features by default, to reduce the resource footprint. It might be useful for netbooks and lower-end systems, or users who want to start with a solid base and build up from there.

It is designed to provide Internet connectivity out of the box and focuses on the following:

  • CD size (<= 700MB)
  • Smaller resource footprint
  • Network-ability (wireless, VPN, dial-up)
  • Internet browsing and social networking
  • Multimedia support
  • Broad hardware support
  • Uses KDE Netbook interface by default (changeable)

As with the full Kororaa release, it includes:

  • Third party repositories (Adobe, Google Chrome, Livna, RPMFusion)
  • Firefox as the default web browser
  • VLC as the default media player
  • Installers for Adobe Flash and NVIDIA drivers
  • SELinux enabled (particularly worthwhile for Flash)

Unlike the full Kororaa, it does not provide these out of the box:

  • Full range of applications (no office suite, PIM, java, or graphics tools, etc)
  • Build tools required for building external modules
  • Extra fonts
  • Printing support

Please test it out and provide any feedback you might have, especially if you have ideas on how to further tweak KDE to reduce resource footprint!


Kororaa 32 bit version released

I’ve had a few requests for a 32 bit version of the Kororaa beta, so I’ve made one and it’s now available for download and testing.


Kororaa is back!

That’s right folks, Kororaa is back.

I know that you’ll be looking for something Linux related to do over your Christmas holidays and New Year 😉 so I’ve just released the first installable Live DVD x86_64 beta for testing. The final release will be Kororaa 14 (derived from Fedora 14), codenamed Nemo. As with the original Kororaa, it’s based on KDE.

If you can find the time, I would really appreciate some feedback. Tell me it’s crap, tell me I suck, but tell me something :-) I’m really looking for suggestions on how to improve it and make sure that everything works. If you’re interested in contributing to a project like this, then here’s your chance!

Essentially, Kororaa has been re-born as a Fedora Remix, inspired by Rahul Sundaram’s Omega GNOME based Remix. I switched to Fedora about a year and a half ago, and I love it. Kororaa has re-emerged out of a desire to see others using Fedora, and so aims to provide a system which sets up a lot of the magic for you, out of the box. This is something I want my family (and all my friends) to be able to install and use. There are lots of things still to do, but I hope you’ll try it out and let me know what you think!

Kororaa aims to provide all general computing uses out of the box (well, as much as possible anyway). It aims to include the software packages that most users will want (this means Firefox for KDE, GIMP over Krita, VLC over DragonPlayer, and OpenOffice.org over KOffice Calligra, etc). Adobe’s Flash plugin and NVIDIA’s graphics drivers are each installable with a double click.

See the About page for a list of what Kororaa aims to achieve, and see the Changes page for a list of customisations and their status.

Here’s a look at the desktop, running from the Live DVD.
Kororaa 14 (Nemo) Desktop


Omega – Fedora for the rest of us

If you’re wanting to try out Fedora, but want all of your multimedia working out of the box, then give Omega a try (a Remix of Fedora). Rahul Sundaram has just released the latest version, Dalmation, which is built on Fedora 14 and available in both 32 and 64bit flavours.

Omega is a completely free and open source Linux based operating system. It is a installable Live image that includes comprehensive multimedia functionality out of the box. It is a Live image that can be optionally installed to your hard disk. Omega is 100% compatible with Fedora and a Fedora Remix only including packages from Fedora, RPM Fusion and Livna software repositories.

If you’re interested in what Omega is all about, I wrote an article on it for Linux Magazine a while back.


How to upgrade Fedora (using PreUpgrade)

Coming from a Debian background, upgrading to new releases is second nature. Unfortunately, Fedora doesn’t seem to have it quite as down pat. Nevertheless, it’s possible and works quite well (but there are pitfalls, so read on).

While upgrading via PackageKit is coming, there’s a pretty decent way of doing it with PreUpgrade.

For the impatient, the steps are:

  • yum update
  • yum install preupgrade
  • preupgrade (reboot)
  • yum distro-sync
  • package-cleanup –orphans (be careful!)
  • package-cleanup –leaves (be careful!)

Now the longer version. First, update your current system:
yum update

Install preupgrade:
yum install preupgrade

Run the preupgrade tool, and follow the prompts (remote upgrades over VNC also supported):

PreUpgrade will prompt to reboot your computer and will update your system automatically. All of your packages should be updated and your repositories configured for you (I also had RPMFusion, Chromium and yum-rawhide which all updated as expected). On one of my systems, even the NVIDIA driver was automatically updated and configured. Now you’re booted into your new Fedora 14 system.

OK, this is where things get a little tricky. Some packages might be no-longer supported, there might be removed dependencies and the like. So, there are two neat commands that we will use to identify these packages, so that you can remove them.

package-cleanup --orphans
package-cleanup --leaves

But wait.. I discovered that there’s a more important step to do first, or you’ll cause yourself a headache!

On my machine, this wanted to remove some pretty important packages, like kdelibs.
[chris@shem ~]$ sudo package-cleanup --orphans
[sudo] password for chris:
Loaded plugins: refresh-packagekit, remove-with-leaves

Fedora (unlike certain other distros I know) provides major updates to the latest versions of packages (like OpenOffice.org, KDE, GNOME, etc). Yay! It’s possible that your new Fedora system is running the same version of, say KDE, as your old one. This was indeed the case with my Fedora 13 to 14 upgrade (both run KDE 4.5.2 at time of F14 release).

Actually, the build of some important packages on Fedora 13 (like kdelibs-4.5.2-8.fc13.x86_64) were actually more recent than on the newer Fedora 14 system (kdelibs-4.5.2-5.fc14.x86_64).

The package-cleanup tool correctly lists kdelibs-4.5.2-8.fc13.x86_64 as being an orphan and if you were to remove this, you’d break your system badly. In fact, if you’re running yum’s brilliant new autoremove deps feature, as I am, you’ll lose most of your system. It makes sense – you are telling yum to remove kdelibs, so it goes and removes everything that relies on it! Yikes.

So first, we need to fix this by running the yum distro-sync command which recognises that we need to downgrade that kdelibs packages (and not remove it!).

[chris@shem ~]$ sudo yum distro-sync
Loaded plugins: refresh-packagekit, remove-with-leaves
Setting up Distribution Synchronization Process
Resolving Dependencies
--> Running transaction check
---> Package akonadi.x86_64 0:1.4.0-1.fc14 will be a downgrade
---> Package akonadi.x86_64 0:1.4.0-3.fc13 will be erased
---> Package kdeedu-marble.x86_64 0:4.5.2-1.fc14 will be a downgrade
---> Package kdeedu-marble.x86_64 0:4.5.2-2.fc13 will be erased
---> Package kdeedu-marble-libs.x86_64 0:4.5.2-1.fc14 will be a downgrade
---> Package kdeedu-marble-libs.x86_64 0:4.5.2-2.fc13 will be erased
---> Package kdelibs.x86_64 6:4.5.2-5.fc14 will be a downgrade
---> Package kdelibs.x86_64 6:4.5.2-8.fc13 will be erased
---> Package kdelibs-common.x86_64 6:4.5.2-5.fc14 will be a downgrade
---> Package kdelibs-common.x86_64 6:4.5.2-8.fc13 will be erased
---> Package schroedinger.x86_64 0:1.0.9-2.fc14 will be a downgrade
---> Package schroedinger.x86_64 0:1.0.10-1.fc13 will be erased
---> Package xorg-x11-drv-wacom.x86_64 0:0.10.8-1.20100726.fc14 will be a downgrade
---> Package xorg-x11-drv-wacom.x86_64 0:0.10.8-2.fc13 will be erased
--> Finished Dependency Resolution
--> Finding unneeded leftover dependencies
Found and removing 0 unneeded dependencies
Dependencies Resolved
Package Arch Version Repository Size
akonadi x86_64 1.4.0-1.fc14 fedora 677 k
kdeedu-marble x86_64 4.5.2-1.fc14 fedora 14 M
kdeedu-marble-libs x86_64 4.5.2-1.fc14 fedora 902 k
kdelibs x86_64 6:4.5.2-5.fc14 fedora 12 M
kdelibs-common x86_64 6:4.5.2-5.fc14 fedora 1.7 M
schroedinger x86_64 1.0.9-2.fc14 fedora 276 k
xorg-x11-drv-wacom x86_64 0.10.8-1.20100726.fc14 fedora 73 k
Transaction Summary
Downgrade 7 Package(s)
Total download size: 30 M
Is this ok [y/N]

Once we downgrade these packages, we can then remove any other orphans we might have, with package-cleanup –leaves and package-cleanup –orphans (I didn’t have any). One last thing to note – Fedora will not replace packages from the newer release if they are exactly the same version. For this reason, you will probably have some F13 packages still installed on your computer – don’t worry, that’s correct. They will be upgraded in time (if required).

So, now I think I know how to successfully upgrade the system without breaking it :-) If anyone has some other tips or corrections, please let me know! Hope that’s helpful.


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
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
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
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
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
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.

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!!