From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030611 Description of problem: aspell in Rawhide recently included pspell functionality. aspell.spec contains the following: Provides: pspell Obsoletes: ispell, pspell, aspell-de < 0.50, aspell-fr < 0.50, aspell-ca < 0.50, aspell-da < 0.50, aspell-es < 0.50, aspell-it < 0.50, aspell-nl < 0.50, aspell-no < 0.50, aspell-sv < 0.50 But... Obsoletes: pspell-devel Two questions 1) How does rpm, up2date, apt and yum behave when a package both Provides and Obsoletes pspell? If pspell functionality is still within this package, why Obsolete it at all? 2) Can Provides: pspell-devel be added? This would be convenient for 3rd party packages that wish to maintain backward compatibilty (not change pspell to aspell within .spec). Version-Release number of selected component (if applicable): aspell-0.50.3-12
from what I can tell yum will treat a self-obsoleting package just like any other package.
In addition to obsoleting pspell*, I guess the lack of pspell-devel provision can be seen as a strong hint to packagers: "Stop using pspell, change to aspell NOW."
I ask for Provides: pspell-devel so packagers wont need to add ugly conditionals to spec files for their SRPM to support RH8, RH9 and TNV. Yes it is not fatal, and we can work with whatever Red Hat decides is best for this package.
Apt doesn't mind about the self obsoleting; I have a few packages doing that and haven't seen problems.
Will add pspell-devel to provides. As for the previous comments, obsoleting and providing at the same time is perfectly acceptable in this case, and with RPM.