Yum behaviour change

When you want to ensure you have the latest version of a package installed, you would configure puppet as follows:

package { "ypbind":
ensure => latest
}

What puppet does, is execute yum as follows:

yum -d 0 -e 0 list available ypbind

If it gets any hits, the package is either available for installation, or eligible for an update, so it'll install the available package. If no packages are "available", it'll just continue like normal.

You will most likely have some file or service definitions depending on the "availability" of the package:

file { "/etc/yp.conf":
source => "puppet://$server/files/yp.conf",
require => Package["ypbind"]
}

service { "ypbind":
ensure => running,
require => Package["ypbind"]
}

When puppet ensures the package to be installed before executing any of the depending definitions, it assumes that yum exiting without any error code is equivalent to the (the most recent version of the) package being installed on the system, and any error code means it can't be done (and thus: not execute the depending statements).

Lately however, yum does throw an error code if there is no package "available" (for installation), and thus all puppet dependencies for that package fail.

Updating anaconda between releases

Some people use a Fedora 7 DVD or the online release tree and then include updates in the installation media they compose using Revisor, so that when they install using this composed media, they do not have to pull in another couple of hundred megabytes of updates.

These people often report errors to Revisor; some fail to compose a multiple (spanned) media set -such as with CDs- because Revisor shits itself (at least from their perspective) during package ordering, or that the installation fails with a nasty RPM error.

One way or the other, both cases are related to a package being updated on which anaconda and anaconda-runtime depend. One of them is yum, the other RPM. Both important, base software without which Fedora wouldn't be Fedora. But so is anaconda.

What we do (as developers) to try and solve the issue, is;

1. exclude the updated package(s) that break their compatibility with anaconda from the updates and updates-testing repositories in our default yum configuration files. This obviously only gets to the end-users when Revisor releases another update, and since configuration files cannot just be replaced ends up in an unused .rpmnew file.
2. exclude the packages that pull in the package we excluded previously to prevent broken dependencies
   
3. work around the issues that may occur in case the updated RPM is installed on the system doing the compose, and it results in any of these errors (anaconda-runtime's pkgorder vs. the RPM update not allowing duplicates in the transaction).

Meanwhile, we can only close tickets and hope users Google the error message they're getting giving them the work-around. I vote for considering updates to anaconda that solve these issues to be allowed between releases, or to ensure updates to the packages anaconda depends upon or uses, do not break anaconda.