Bug 66889 - RFE: erase obsolete packages on upgrade.
Summary: RFE: erase obsolete packages on upgrade.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-18 03:02 UTC by Aleksey Nogin
Modified: 2014-03-17 02:28 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-03-01 20:46:52 UTC
Embargoed:


Attachments (Terms of Use)

Description Aleksey Nogin 2002-06-18 03:02:59 UTC
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):

isapnptools 
ircii 
enlightenment 
fnlib-devel 
fnlib 
metamail 
ee 
gmc 
extace 
mawk 
gnome-linuxconf 
xsysinfo 
xlockmore 
kpm 
gnorpm 
gphoto 
db1 
elm
control-panel 
pythonlib 
tksysv

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 19:45:59 UTC
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 19:54:03 UTC
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 21:30:53 UTC
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 20:46:52 UTC
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.