On Tue, Dec 06, 2005 at 02:23:29PM -0500, Jeff Spaleta wrote:
Also, the obsoletes tags in such a package would need to precise, so they match the version-release of the latest Core/Extras package but not beyond that, so that there wouldn't be a problem with other repos providing the same package.
I think you missed my point. Is it appropriate to make functionality "disappear" on a client system via update packages that serve no purpose other than to obsolete other packages?
I agree with you that this shouldn't happen in updates to released versions of Fedora.
Package foo in core provides /usr/bin/foo which can be scripted in bash scripts. Core decides to remove package foo in fc5 and it has not been added to Extras yet.
If it's known that package is going to be added to extras at some point soon, that package probably shouldn't be added to the obsoleted-packages list.
The foo package from fc4 has no unfullfilled
deps which prevent it from installing and running on an fc5 system.
I'm more concerned about the ones that do have broken deps, which seems to be a lot of the time in cases like this.
Why should an fc4 user who is relying on the functionality provided by package foo be forced to remove that package via the payload-less obsoletes package? We aren't talking about packages that have changed names or sub-packages that have been re-structured. We are talking about packages that have no functional replacement yet in the available Fedora repos. Why should an update/upgrade force the removal of such packages and functionality on client systems? Isn't this situation a case-by-case determination for the local admin?
It still could be; the obsoletes-packages RPM would just be a tool to help if you decide to go that way.