Bug 66889 - RFE: erase obsolete packages on upgrade.
RFE: erase obsolete packages on upgrade.
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2002-06-17 23:02 EDT by Aleksey Nogin
Modified: 2014-03-16 22:28 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-01 15:46:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2002-06-17 23:02:59 EDT
I have a machine where I did 6.2->7.1->7.2->7.3->Milan beta2 (and may be some
other versions in between and before 6.2).

I see that I have a big number of packages that really have no business still
being around. We clearly need to add a few "Obsoletes" tags here and there. For
example, the old configuration tools that are no longer supported
(control-panel, tksysv, ...) should be obsoleted by modern configuration tools.
The isapnptool package should probably be obsoleted by modern kernel packages. 

OTOH some packages may be obsolete "in general", but not by a particular modern
package. What's the correct way of dealing with them? How about making them
obsoleted by the "redhat-release" package? Or should anaconda have it's own list
of things to erase on upgrade?

Here is a (very incomplete) list of packages that should probably be obsoleted
(in no particular order):


Please consider this bug a general push for more "Obsoletes" line in the spec
files. If you agree that such push is needed, I would try to file a bunch of
more specific RFEs.
Comment 1 Michael Fulbright 2002-06-19 15:45:59 EDT
Assigning to an engineer.

Jeremy - doesn't rpm just take care of this if the Obsoletes are right?
Comment 2 Jeremy Katz 2002-06-19 15:54:03 EDT
We'll do the right thing if something is actually obsoleted... but some of
these, you really don't want an obsoletes for (ie: people would get really
annoyed if we started removing the enlightenment rpm that they installed by hand
on an upgrade or similar for many of those packages). 

Reassigning to distribution
Comment 3 Aleksey Nogin 2002-07-11 17:30:53 EDT
Would it be a good idea to add an extra screen to the upgrade process:

We detected nn packages from older versions of Red Hat Linux that are outdated
and/or no longer supported in the current version of Red Hat Linux. You can
choose one of the following:
[*] Erase all outdated packages
[ ] Choose which outdated packages to keep
[ ] Keep all outdated packages

This can be implemented in a very concervative way if desired - for example,
have a somewhat small list of packages that should be considered outdated and
even for those listed only consider them outdated if Packager=RedHat. Or less
conservatively - just consider all packages with Packager=RedHat to be outdated
if they are no longer present in the current release and are not Obsoleted by
anything in the current release (and may be have a list of exceptions for
packages that are temporarily removed, but may be re-added back later).

Of course, this selection should take place before any dependency checking so
that erased packages do not pull in any compat libs.

What do you think?
Comment 4 Bill Nottingham 2005-03-01 15:46:52 EST
Closing - I'd find the idea fo something like that unlikely; maintaining a
continually updated list of what's obsoleted back through all releases isn't
practical, moreover, there's not a good way to distinguish what's just left over
versus what may have been intentionally reinstalled.

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