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.
Assigning to an engineer. Jeremy - doesn't rpm just take care of this if the Obsoletes are right?
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
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?
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.