Red Hat Bugzilla – Bug 156106
Anaconda should warn about packages *not* upgraded
Last modified: 2008-05-06 20:09:31 EDT
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):
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
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:
(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 firstname.lastname@example.org'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:
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: