Bug 156106 - Anaconda should warn about packages *not* upgraded
Anaconda should warn about packages *not* upgraded
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Mike McLean
bzcl34nup
: Reopened
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2005-04-27 12:37 EDT by Steve Lacy
Modified: 2008-05-06 20:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:09:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Steve Lacy 2005-04-27 12:37:42 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):


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".
Comment 1 Jeremy Katz 2005-04-27 14:34:48 EDT
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.
Comment 2 Steve Lacy 2005-04-28 01:34:38 EDT
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.
Comment 3 Steve Lacy 2005-04-29 14:57:28 EDT
There is an interesting discussion about exactly this issue here:

https://www.redhat.com/archives/fedora-devel-list/2005-February/msg01355.html
Comment 4 Rahul Sundaram 2005-08-23 15:23:26 EDT
(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

Comment 6 Red Hat Bugzilla 2007-02-05 14:22:15 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 7 Red Hat Bugzilla 2007-08-21 01:19:58 EDT
User pnasrat@redhat.com's account has been closed
Comment 8 Bug Zapper 2008-04-03 12:07:17 EDT
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.
Comment 9 Bug Zapper 2008-05-06 20:09:30 EDT
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

Note You need to log in before you can comment on or make changes to this bug.