March 19, 2012

A week and a half ago I posted about func-vhost-reboot. After that is working and functional I realized I needed a func-host-reboot, too -for the non-vhost-wide reboots.


it’s pretty simple – it reboots a set of hosts and checks to make sure they all come back online. It also adds a ‘–one-at-a-time’ option which is pretty handy. For example if you want to bounce all your nameservers for some reason but you don’t want them ALL to be bouncing at the same time. Then you’d pass –one-at-a-time or -o. It will reboot them each at a time, waiting for the one being rebooted to come back before proceeding to the next one.

If you find all rpm and yum operations EXTREMELY slow – even doing  simple things like listing all installed pkgs – it would be handy to take a look at the numbers you’re getting.

A bug filed today:


has been able to replicate it.


However, if you would like to check it on your system in general please run:

time python -c ‘import yum; print len(yum.YumBase().rpmdb.simplePkgList())’

This will spit out a number and then some times. The times are obvious – the number is the total number of pkgs installed on your system  – according to your rpmdb.

If the time is beyond like 20s it’s way too slow. On my laptop it is between .12s and .78s.

Seriously – it shouldn’t take very long at all. if it is taking a long time – post your numbers in a comment on this blog post and what ver of rpm you’re using.




on pto – but about yum

September 20, 2011

I’m on PTO this week to get some downtime but I got to read the discussion about yum from the ticket I opened for fesco.

A few  things that seem to be widely misunderstood:

1. rpm does not have a depsolver. You can pass rpm a set of pkgs/hdrs and it can tell you if they are a complete transaction, if they have missing deps or if they conflict. It can’t tell you how to solve the problem – just that there IS a problem. rpm doesn’t know anything about repositories or configurations, plugins, etc. That’s ALL in the depsolver/package manager above rpm. In this case in yum.

2. librpm peforms the actual transaction. Yum mediates the transaction – it provides rpm with where the rpm pkgs are and provides a callback to tell the user what is going on. Yum also tries to track what is going on so that if something goes off the rails yum can try and recover.

3. When yum started out – it used rpm for everything. Yum was just a mechanism of indexing pkgs. It would take pkg headers, chuck them into a transaction set and ask rpm ‘tell us what is missing and we’ll find it’. That ate memory like there was no tomorrow and would not scale with many thousands of packages. I doubt yum 1.0 and 2.0 would be able to run, at all, with a modern number of pkgs like fedora currently has.

4. Yum was moved away from that partially by James Antill, Jeremy Katz, Paul Nasrat, Menno Smits, Tim Lauridisen, Florian Festi, Panu Matilenen and me.  The move away consisted of traversing the set of pkgs intended for the transaction (and their deps/provs) in yum itself and figuring out what deps were missing that way, rather than building up an rpm transaction set and asking rpm what was missing. Florian Festi and James Antill did an enormous amount of that work. It resulted in a speed up and gave yum more control over the depsolving process than was available before. Rpm was always used as a back-check at the end, though to confirm consistency.

5. For a very, very long time yum needed to use rpm-python for A LOT of things. From verchecking to just accessing the rpmdb. In recent time this dependence has been reduced. It has allowed faster access and simpler access (especially to the rpmdb).

6.  Every depsolver in the rpm-universe makes subtly different choices and therefore has potentially different results. Depsolvers deal with errors and issues in different ways. A lot of the behaviors people think of as yum-specific are adopted, originally, from the choices anaconda (and up2date) made in the Red Hat Linux days. (shortest-name-wins is an example of this). Yum made those choices as to remain consistent. Consistency in package dependency resolution is more important than other kinds of precision.   One of the reasons anaconda and other tools moved to using yum for their dependency resolution was specifically so we could have consistency across the board both at install-time and post-install. Consistency matters b/c at the end of the day the depsolver is impacting the files on a running system. The user/admin needs to be able to know that an action will return the same results on multiple systems – and that doing a transaction of pkgs post-install will result in the same thing as adding the pkgs in a kickstart %packages section.

7. Every depsolver has evolved and changed with the set of pkgs and the way they interact. It is worth noting that a resolved set of dependencies does not mean it is the CORRECT set of pkgs. It just means that the dependencies/provides are a closed set w/o conflicts. All depsolvers can resolve a set of dependencies but which set of pkgs are CORRECT has changed over time. What ends up happening is a case creeps in where the resolved package set that comes out of a case is not what the user wanted. If the case is obvious incorrect enough or the user is powerful/demanding enough  then the rules change to meet that demand. As this has always been true (in every depsolver)  it means a depsolver must evolve its mechanism over time. The end result is that no depresolution scheme is ever finished. It is just finished vis-a-vis the set of rules and demands of the users/packages at that time. So any depsolver will require long-running maintenance work to keep it accurate to the ever-changing requirements of users.


January 12, 2011

This came up in a discussion last week so I thought I’d work up a
functional plugin to let people enhance.

Yum currently has some nifty verify() functionality – mostly exposed on
the cli via the verify plugin. It does all the things that rpm -V does
but it has nicer output and can be configured a lot more.

One thing that’s always bugged me is that in all the verification
processes we’ve never taken into account the checksums or other value
changes that we intentionally make and know about in config management
systems like cfengine, bcfg2 or puppet.

In yum, now, we have a plugin hook for the file verification process for
this specific point. It allows us to  add in the values that we should
see from the config mgmt system so that if the files on disk don’t match
what was originally in the rpm package but do match what we intended to
see from the config mgmt changes then it doesn’t alert about it.

So here’s the reverify plugin and accompanying scripts – just a simple,
working, proof of concept.

obviously change the paths to not be in my homedir. 🙂

orphaned dep cleanup in yum

November 9, 2010

I just checked this into yum on friday. It’s currently defaulting to off but I wanted to mention it so it gets more testing.

if you set:

clean_requirements_on_remove = 1


in your yum.conf under [main]

or use:


on the command line, then yum will remove no-longer-needed dependencies of pkgs that you are removing from your system.

Yum was sorta able to do this with the remove-with-leaves plugin but remove-with-leaves did kinda a poor job of it and we weren’t using the ‘reason’ info we’re now storing in the yumdb to know what is a dep and what is not.

Now we are. I’ve tested this in some kinda bizarre scenarios and it seems to work right but I’d appreciate more testing.

Yum that went into rawhide today (3.2.28-13) has this patch and testing (and filing bugs) is appreciated.




September 30, 2010

Just finished typing up:

since this is the 3rd time in 3 days I’ve been asked what the option is for yum for –nodeps, –force

In the last round of roll outs the fedora packagedb added tags and ratings to the site. A great bit of work by mbacovsk, maploin and toshio made this happen. I added support for yum to use the db  that the pkgdb can spit out, searching on the tags for pkgs, provided that the info is in the repodata. It’s not quite percolated to the top of anyone’s list to get it into the repodata in bodhi. However with the advent of repos.fp.o I now have a good place to store this and make it accessible to users.

So make sure you have yum updated on your system – at least yum 3.2.26.

1. Grab this file: and stuff it in /etc/yum.repos.d/ on your system

2. run: yum search sometag someothertag someothertag

That’s it!

I’ll update the repo ever so often until the round-tuits are compiled for it to be added into the updates repodata automagically.

Yesterday someone was talking about installing apps in fedora and how it was hard to figure out what to install/try b/c there were too much STUFF in fedora. They suggested an ‘app store’ like functionality. I explained that all the resources to do something like that exist in the infrastructure yum and friends offer now. I decided to prove that concept a bit.

The concept of an ‘app’ is pretty amorphous but I decided to just use what Colin Walters said was his definition of an ‘app’ – which is any pkg containing a .desktop file. So I just whipped up a simple tool to dump out an xml-file of a format yum is already familiar with based on that criteria:

Running that generates an xml file with only the ‘apps’ defined.

Great. Then I wrote a yum plugin to access and use this data.

and I stuck it in this repo

1. copy this file into /etc/yum.repos.d/

2. run: yum install yum-plugin-appmarket

Now yum will have a few new commands available to it:

app-install    Install an App
app-list       List Apps
app-remove     Remove an App
app-search     Search for an App

Some examples:

yum app-search yum

won’t turn up ‘yum’ but it will turn up ‘yumex’.

Fancy, huh?

Now, the concept of an app can be refined in many ways but this is just to prove that the infrastructure has been available.

repoquery docs

June 22, 2010

Typed up some docs on repoquery since it seems like we answer a lot of questions about it and it is VERY commonly used.

This and other yum/yum-utils/createrepo/etc docs can be found at:

additions/comments welcome.

A friend pointed me at:

which ultimately pointed me to:

which annoyed me b/c it had a deb but no rpm. So I made one

if you’re a f13 user you can run:

yum –nogpgcheck install

and it will install it (and it’s one dependency) for you.

no, I’m not submitting it to fedora b/c I don’t know if I’ll use it and therefore not sure I want to maintain it.