+++ This bug was initially created as a clone of Bug #705350 +++

Description of problem:
During upgrades in the #fedora IRC channel we've often seen upgrades (during or post upgrade) fail due to dependency problems caused by third party apps.  This is especially a problem if the upgrade is an offline upgrade without the third party repos made available, but even that cannot be assumed that they are up to date for the new Fedora release.

My suggestion is that in the URL I'm referencing:  http://docs.fedoraproject.org/en-US/Fedora/14/html-single/Installation_Guide/index.html#ch-upgrade-x86

In this section:  19.1. Determining Whether to Upgrade or Re-Install

In future documents this line be updated:  Third party or ISV applications may not work correctly following the upgrade. 

Someone will want to wordsmith it of course, but I'd suggest something more along the lines of "Third party or ISV applications may not work correctly or may cause problems during the upgrade process and it is suggested you temporarily remove all third party repos and packages during the upgrade.  You may reinstall them after the upgrade process succeeds."

Version-Release number of selected component (if applicable):
Looking at the 14 docs, do not see the 15 yet so I cannot verify if this has been modified since.

How reproducible:
The upgrade problem itself is hard to say how reproducible, but it has been an issue in the past and this is a fairly easy change to make.

Steps to Reproduce:
n/a
  
Actual results:
I'll reflect on what happens if the upgrade fails here.  In my personal experience I've seen the upgrade process itself fail because of a dependency of an application that the upgrade process had to upgrade.

More often what I've seen and we've seen in the #fedora IRC channel is that post-upgrade there are old versions of applications that did not get upgraded in the upgrade process.  One of the notable ones was for me I had Python not upgrade because of a third party package installed and none of the Fedora tools would work, including Yum.

Expected results:
Not sure how much we can do about this in Anaconda, but we can at least document it.  :)

Additional info:
A quarter has 119 grooves on its edge, a dime has one less groove.

--- Additional comment from jlaska on 2011-05-17 09:03:54 EDT ---

Note, when using the documented upgrade procedure (DVD or preupgrade), users will not hit problems on upgrade.  The installer understands the problems with 3rd party packages, and ignores dependency problems on upgrade.  However, the user will be required to manually adjust their systems post-upgrade.

My only concern is that I don't want to start documenting any unsupported upgrade methods (yum update or yum distro-sync).  Those are clearly not recommended and should continue to be so ... https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum

Any guidance on upgrading using yum may be best left to the wiki doc (see above).

--- Additional comment from wally on 2011-05-17 09:52:35 EDT ---

James,

Is this new behavior?  If so, then that might take care of the primary case here, and the supported one (DVD/CD or Network Upgrade using the media vs using yum.

I believe the Python failure to update I personally had was upgrading 10 to 11 using DVD, but we've had others in the #fedora IRC channel since but can't really come up with specific examples or versions offhand.

I agree that if this is new-ish behavior (ie: My observations are no longer an issue) we shouldn't necessarily document this for unsupported upgrade methods.  And also, if it's a yum upgrade at least the user has visibility to the issue.

--- Additional comment from jlaska on 2011-05-17 10:16:52 EDT ---

(In reply to comment #2)
> James,
> 
> Is this new behavior?  If so, then that might take care of the primary case
> here, and the supported one (DVD/CD or Network Upgrade using the media vs using
> yum.

It shouldn't be a new behavior, I believe this is something anaconda has done for a long time now.  However, it's possible it was broken for a period of time.  There was a bug in the F15 cycle where it wasn't ignoring deps (see bug#678201).

http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=pyanaconda/yuminstall.py#l1492

Now it's possible that there could be file conflicts present in packages, that would most certainly break an upgrade 

> I believe the Python failure to update I personally had was upgrading 10 to 11
> using DVD, but we've had others in the #fedora IRC channel since but can't
> really come up with specific examples or versions offhand.

Yes, there are plenty of examples.  I think the important thing when triaging issues on #fedora (or #fedora-qa) is to first clarify the type of upgrade performed.  Whether it was an anaconda DVD-only upgrade, anaconda network-repo upgrade, or a 'yum' upgrade.

> I agree that if this is new-ish behavior (ie: My observations are no longer an
> issue) we shouldn't necessarily document this for unsupported upgrade methods. 
> And also, if it's a yum upgrade at least the user has visibility to the issue.

At the very least, I think your bug highlights that we should warn users about non-Fedora package repositories.  I like the idea of keeping the 3rd party package paragraph intact, but perhaps modifying the following ...

   "If you have one of Red Hat's layered products (such as the Cluster Suite) installed, it may need to be manually upgraded after the upgrade has been completed."

To perhaps ...

   "If you have additional third party package repositories (such as rpmfusion) enabled, software installed from those repositories may not function properly after upgrade.  Fedora does not maintain third party packages, and cannot guarantee that such repositories are up to date."

--- Additional comment from jreed on 2011-10-24 19:08:12 EDT ---

Thanks Walter and James.

I've replaced the bullet point in section 20.1 in the Fedora 16 version of the guide with the revision James suggested.

You can check out the draft version here - http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Installation_Guide/ch-upgrade-x86.html#id863129

Cheers,

Jack

--- Additional comment from wally on 2011-10-24 19:19:11 EDT ---

Awesome, thanks Jack and James!  Glad to see this go into the documentation.