Explaining: "Warning: RPMDB altered outside of yum."
What does it mean?
The yum message "Warning: RPMDB altered outside of yum." or, as the yum message said for a few months, "Warning: RPMDB has been altered since the last yum transaction." means some application has altered the rpm database (installed or removed a package) without going through the Yum APIs. This is almost always due to someone using rpm directly (Ie. rpm -ivh blah.rpm), but another possibility is an application built on top of the rpm APIs (Ie. smart, apt, zypp). While it's possible that someone has hacked your machine and altered the rpmdb maliciously, it would have to be done poorly to trigger this warning.
Why has yum started to emit this warning?
There are three main sets of reasoning behind bringing this to the users attention.
New yum features require yum being "the" packaging API
There are now a few features in yum, requested by users of the package management system, that require yum is aware of all package actions on the system. Here a few of the current ones:
The most obvious example is "yum history", which records when packages were installed, when and by whom. If yum is not involved in installing/updating/removing/etc. some packages then a lot of the benefits of "yum history" are gone. For instance there is no useful audit trail anymore, you can't use "yum history list blah" and know you have all the instances where something happened to "blah". Yum now has it's own database, for package information it wants to record but has no corresponding entry in the rpmdb, the obvious example is "the id of the repository that this package was installed from" but there are quite a few pieces of info. now. Following on from the previous point, rpmdb versions are a significant feature for managing many machines by yum. They require information from the yumdb, so installing something via. yum on one machine but via. rpm on another would give the machines different "rpmdb versions".
This is not a complete list, and as more package management features are implemented they are much more likely to be implemented at the yum layer than at the rpm layer. Not because rpm is bad, but for the same reasons that the above features were implemented in yum, it's much easier and faster to implement them there.
Rpm is often abused, when used directly
We, the yum developers, often find that people using rpm directly only do so to solve problems in a way that just creates more problems (and often looks like yum is at fault). For instance using any of --force, --nodeps, --justdb is pretty much outright lying to yum, and is pretty much guaranteed to confuse yum vs. rpm. For instance over the last 3 months, over 10% of the bugs we've had against yum have been due to this kind of problem (and probably very close to 100% of bugs about "rpm doesn't like the depsolving solution yum did").
There is also the problem of users accidentally using "rpm --install" which is very different from what yum thinks of as an "install" operation. Which, again, just creates problems and even if yum works around these it is unlikely to do so in a way the user wished.
In addition to the problems it creates there are no known reasons to use rpm instead of yum. Over the last year or so yum has added features like the downgrade and reinstall commands (which obsolete using rpm --oldpackage) and are generally much easier for the user (in this case esp. combined with yum history undo/redo). Recent versions of yum will even allow you to do things like "yum install http://example.com/blah.rpm" which was the last use case where you could easily do something with rpm and not with yum (and even then we also changed yum so we could add the --releasever, which is a much easier solution to the common reason why people want http installs). But if you can think of something that is easier to do with rpm, we'll almost certainly add a feature to yum to solve that problem.
We do extra work, and so inform the user
We now do a non-trivial amount of work when we detect that something has happened to the rpmdb, including a full "yum check" run, so that yum can show problems as close to their source as possible. Just stopping yum for a significant amount of time, or outputting problem reports, with no context would not be a good way to interact with the user. We are also able to cache rpm data, and thus. have yum run faster, when yum is aware of all rpmdb operations (so again, we'd want some way to let the user know: yum is running slower, and this is why).
What can I do to make it stop?
The most obvious solution is the one we recommend: Only use yum, or tools that use yum APIs, to install/update/remove/etc. packages on your system. If you don't like yum, and prefer to use some other packaging system that's fine but we'd assume you'd want to use that system all the time (and thus. it doesn't matter what yum does or doesn't do, as you won't be using it).
If you think you really need to use yum some/most of the time but something else the rest of the time, then there is a way to currently turn all this checking off. In your yum.conf set "history_record = false", and yum will not record any history (the "yum history" command will be useless) but yum will also not be able to tell when the rpmdb has changed. This will break other features, like the yumdb, but it will stop the warnings.
Known problems
Old versions of the "remove-with-leaves" yum plugin called an API which would corrupt the state yum thought the rpmdb was in. Older versions of the "keys" plugin may also have been affected. This meant that the warning was produced all the time, and yum history would not be happy. Newer versions of yum fixed the APIs affected.
The akmod packages seem to work by calling rpm directly, and thus. operating without yum's knowledge, they need to be fixed.