Description of problem: Anaconda should offer warnings for packages that are *not* going to be upgraded. I have been burned several times by a FC installation not including packages that were previously supported, and anaconda is happy to just install away and leave me high and dry with non-functional packages from a previous installation. It should offer a fairly "harsh" warning showing every package that is *not* going to be upgraded, and say "your system may not be functional if you continue" and "would you like to remove these packages and continue" etc. Version-Release number of selected component (if applicable): How reproducible: Upgrade from FC1 runnning "imapd" and note that FC2 does not include "imapd" it only includes "cyrus-imapd.". Upgrade from FC2 to FC4 test 2 and note that it does not include "cyrus-imapd" only "dovecot".
These could just as well be packages which you installed from another source and plenty of them will work. You can do this sort of cleanup as a post-upgrade step.
If you don't consider pacage dependencies, then what you said is correct. But, as we know, packages depend on each other, and this is the root of many of the issues -- libc upgrades break previous installs of packages that are no longer supported. Nonetheless, I propose a new algorithm: While installing distrobution version "N", any package that is known to have been distributed in in versions starting with N-m (for m>1) and running through N-1, a warning should be displayed. NB: are there really *that* many external packages that people have installed? NB2: Why not an option that says "Check for packages that are not being upgraded" and offer the user a choice. This is a real problem, and should be addressed. You can't just break working configurations every time you upgrade, telling the user to "fix it after the machine comes up" when the user has absolutely no idea what is going to have to be fixed, and the only way to know is to run through the upgrade.
There is an interesting discussion about exactly this issue here: https://www.redhat.com/archives/fedora-devel-list/2005-February/msg01355.html
(Reassiging from FC2test1 to devel) A few important things to consider. A long rant This enhancement is a workaround really. What we should be aiming for is better ABI stability in the core platform to avoid breakages during updates. Almost all installations seems to have several external packages installed. Fedora Extras is increasing covering a whole lot of new packages that simply werent available to Fedora users in a easily installable fashion before. For FC4, this extras repository was enabled by default. so a yum update immediately after installation would have taken care of say Abiword or XMMS which was available in extras by then. The installer is getting the ability to use external repositories besides core which also includes extras along the FC5 timeframe. So repositories which stay in sync by rebuilding packages against changes that happen in Fedora that can coverup ABI breakages most of which that happen in the upstream projects. This along with backports to older releases is how centralised repositories in general provide the impression of stability. As Fedora core, gets trimmed we can expect many important stuff to move over to extras instead of being just dropped but there are many packages that arent going to be in any of the Fedora repositories because they are proprietary or restricted (third party repos could take care of this) , experimental, noone bothered to package them for the particular Fedora etc and hence it would remain a useful option if we can detect which packages break or avoid such breakages in the first place if we can. If we consider avoiding breakage as a important functionality we need to ensure better ABI stability. Along similar lines, lets say a user has a external package which isnt in any of the official Fedora repositories. example: RealPlayer and that depends on a legacy library, we can consider installing it by default or enabling the legacy group on that instance In the future when Fedora Core really means the core stuff we can ensure that the core platform or nucleus remains relatively stable (read:stagnant) for a longer length of time ensuring that breakage doesnt happen regardless of whether other packages beyond the nucleus rapidly changes or evolves and irrespective of whether such packages are in the repositories or not which is the ideal definition of a good platform
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
User pnasrat's account has been closed
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp