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. -- Matthew Miller mattdm@xxxxxxxxxx <http://mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
