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
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
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):
from what I can tell yum will treat a self-obsoleting package just like any
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
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.