Bug 592356

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.