Tag Archive for 'package'

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."
     https://launchpad.net/deja-dup/+announcement/7239

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 :-)

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

Yum gets autoremove dependency feature

Coming from a Gentoo/Debian background, one thing that has constantly bugged me on RPM based platforms like Fedora is the lack of decent, reliable dependency removal.

It seems so simple (and Debian has done it since the dawn of time) – if I install package x which pulls in dependencies y and z, then when I remove package x, I want to remove dependencies y and z, if they are not required by any other package.

Yes, there is the remove-leaves plugin for Yum and various RPM orphan checking tools, but in my experience, they are just not reliable.

So, I’m very happy to have discovered that Seth Vidal has merged orphaned dependency cleanup on removal into Yum. Hallelujah!

It’s in rawhide yum-3.2.28-13, and I’ll do some testing soon…

Yum still on the menu?

Update: I’ve tried to post my results back to Seth’s thread but it won’t work, so I’ve emailed him instead.

In response to my article comparing Yum and Apt (at least I think it was my article, might have been someone else’s I guess), lead developer of Yum, Seth Vidal, wrote his own test script and performed some Yum benchmarks of his own.

He wrote:

Always a fun comparison. It’d be even more fun if any of the numbers seemed accurate.

His ran his test and concluded that Yum is “pretty good” and offers for others to run the test and post their results. So I did, on the same computer I used for the my article. I also compared the results to Ubuntu, as that’s really what my article was talking about :-)

So what did I find?

Continue reading ‘Yum still on the menu?’

Having Yum for Breakfast

This week I decided to write a comparative article between Yum and Apt (the package managers). Using Fedora 11 and Ubuntu 9.04, I performed various tests and benchmarked both the time and CPU usage they took. But why? Let me explain.

I really like the Fedora project. Really. I like their stance on proprietary drivers and codecs (and of course free software) and these days they seem to be pushing the technological envelope more than others. Sure Red Hat drives the direction of the project somewhat, but I don’t mind Red Hat either.

In fact, I wish I could use Fedora as my main distro! But every time I try it I just get so frustrated with Yum. Sure it’s better than up2date, but it’s so damn slow and annoying. That’s a problem for someone like me who manually updates his package database first thing every morning and checks to see what packages are available and updates the system by hand. Why do I do that? Cause I like to.

But every time I’ve tried to get into Fedora that damn package manager has stopped me. I get frustrated after a day or so. I think the longest I’ve had it on was 2 days before I switched.

Recently I installed Fedora 10 and 11 to see if there was any performance increase. Actually, to tell you the truth I was completely surprised by Yum’s agility and speed. The old Fedora I remember was not to be seen.. or so it felt like anyway.

Hence, I thought it might be good to run some tests to see.

Of course as the article points out, does any of this matter? Do we really need a fast a nimble package manager? Well for me it matters. It matters a great deal. For most users though they probably won’t care, as they just let the package manager do its thing in the background.

Still, it makes for some interesting thoughts. I think.

Security, ahh, update?

This morning I turned on my openSUSE work machine and was greeted (as I often am) with a message to update the system.

Today’s message was special however, and perhaps one for The Daily WTF.

I wonder whether “Do not warn me again” means

Don’t tell me when there’s a non-existent update again

Still, it seemed pretty important so I did it straight away!

It’s good to know that I’m protected from security threats so real, they cannot be named :)

P.S. If you’re wondering what awesome icon set I’m using, it’s Oxy-GNOME.