Attempting to upgrade to F12 from a fully updated (as of time of writing) F11 system. The version of httpd in F11 has a higher version (2.2.15-1) than the current F12 version (2.2.14-1). I notice in koji that a 2.2.15-1 package set for F12 has been built but not pushed out yet. This causes an upgrade attempt from F11 to F12 to fail. Because the version number appears to go down, yum will not update the httpd-* packages. But openssl does get upgraded which removes a dependency (libssl.so.8()(64 bit) and libcrypto.so.8()(64 bit)) from under the feet of httpd-tools, which httpd itself depends on. This is not fixable with --skip-broken. A workaround is to "rpm --force --nodeps" downgrade httpd to the F11 non-updates release version 2.2.11-8. The F12 packages then look newer and are selected for update. This could be seen as either a failure in yum to notice that the f12 version is later than the f11 version even at a lower patch level (you can see it as sort-of/sort-of-not a later version number depending on outlook), or as a failure of process: if this is a known limitation in yum then later fedora-release versions of packages ought to be pushed out before earlier release versions to prevent upgrades from failing.
In very recent versions of yum we have a "distro-sync" command which will hopefully help in these cases. That isn't going to go back to F11 (and maybe not F12). Going to change the version to 12, as I change the package, because that's the version that needs updating.
(Is distro-sync intended to become the recommended upgrade mechanism for f13->f14 and onwards as described on http://fedoraproject.org/wiki/YumUpgradeFaq - which is what I always refer to when upgrading?) While pushing the new httpd-*.fc12 version will fix this particular instance, this time, it does little to prevent the general problem of pushing out packages in forwards order of fedora release breaking attempts to upgrade. If a policy decision has been taken not to make yum automatically detect this kind of situation (and either work around it or provide useful diagnostics[*]) for either f11 or f12 then it ought to become part of the formal release process that packages are pushed out in reverse fedora release order to prevent the situation from arising in the first place. (If the tool used to push packages can be made to check for this and issue a warning all the better.) [*] To fix the problem I had to make inferences from what *wasn't* present in the copious "yum upgrade" output - doing various --requires and --depends probes to discover the related packages around the one mentioned in the final yum error message, then noticing that some of them just weren't mentioned in the list of packages yum wanted to update, digging out the 4 repo baseurls, noticing the version disparity (amongst several possible alternative hypotheses) then --force --nodeps downgrading packages until the problem disappeared. A small PITA for me perhaps but a hopeless situation for less confident users, with as far as I can tell no (or no easily discoverable) description of this particular issue and resolution to help. (FWIW although this wasn't the only issue I had to work around during the upgrade, the others were mostly obvious and "clearly my own fault", and the entire process was a lot less painful than any previous upgrade going back to fc5.)
It's very possible that distro-sync will become the default recommended method, on that page, when it's widely available. However I doubt "upgrade via. yum" will become supported by Fedora due to it. > If a policy decision has been taken not to make yum automatically detect this > kind of situation (and either work around it or provide useful diagnostics[*]) The latest upstream/rawhide yum also contains a bunch of changes to the diagnostics when depsolving fails. It will probably not help the "normal" user, but it should save you time in working out what the problem is. Eg. % yum update -x qt-sqlite qt [...] Error: Package: 1:qt-sqlite-4.6.2-16.fc13.x86_64 (@fedora) Requires: qt(x86-64) = 1:4.6.2-16.fc13 Removing: 1:qt-4.6.2-16.fc13.x86_64 (@fedora) qt(x86-64) = 1:4.6.2-16.fc13 Updated By: 1:qt-4.6.2-17.fc13.x86_64 (updates) qt(x86-64) = 1:4.6.2-17.fc13 Error: Package: 1:qt-x11-4.6.2-17.fc13.x86_64 (updates) Requires: qt-sqlite(x86-64) = 1:4.6.2-17.fc13 Installed: 1:qt-sqlite-4.6.2-16.fc13.x86_64 (@fedora) qt-sqlite(x86-64) = 1:4.6.2-16.fc13 > If the tool used to push packages can be made to check for this and issue a > warning all the better Yes, as I understand it, auto-QA is supposed to do this ... and is really close to happening now. Of course packagers should have been doing it on their own, but there are almost always a couple that forget/etc.
yum upgrades will almost never be the default. The simple reason is that there are certain kinds of updates you cannot do on a running system. Partition/VM/dev underlying changes, as an example. Like with home renovation - when you're replacing the floor joists and support piers it is a good idea to move out for a little while.
The thought of not having an active shell and web browser at the point that dependency resolution wedges itself up gives be the screaming heebie-jeebies ;-) That said, using the yum upgrade method there comes a point when all the inevitable conflicts have been manually resolved, the machine has been rebooted into a consistent set of packages/libraries and kernel, and various third-party kernel dependencies (previously VMware and nVidia drivers, though I've ditched the nVidia supplied drivers now) have been beaten into submission under the new kernel and the system appears relatively stable again. If upgrading via Anaconda would have made extra changes outside of the running system other than just updating packages, is there a way to list what these changes would have been and get them to happen as an extra "post package upgrade" step? (For bonus points is there a way to find out all the things I've missed out on from using the yum upgrade methods all the way back to FC5?)
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.