On Monday 21 July 2003 17:33, Olivier Thauvin wrote: > Le Mardi 22 Juillet 2003 01:55, Andi Payn a écrit : > > > I have a workaround, do not report when a rpm obsolete itself except > > > when it obsolete it %name (this last case is not normal, a new version > > > obsoletes an older of course). > > > > I didn't think about that special case (because I never saw it happen), > > but that sounds like it should be flagged. > > Are you sure: > > %define TDSVER 7.0 > %define name freetds > %define release 1mdk > %define version 0.61 > > Summary: An OpenSource implementation of the tubular data stream > protocol. Name: %name > [...] > %package devel # This mean the package will be name freetds-devel > [...] > Provides: freetds-devel > Obsoletes: freetds-devel > > No comment.
The question is, why does freetds-devel provide freetds-devel in the first place? Unless there's some reason that I'm missing, this has to be a mistake. In which case this package should be flagged (even though it doesn't do any harm). Are there any examples where a package obsoletes %name but doesn't also provide %name like this? Meanwhile, I've been thinking about the general use of obsoletes to replace old packages. I need to do some more testing, but I'm not sure it's needed at all with rpm-4.2 In other words, I think that if package foo provides bar, and you install foo, rpm-4.2 removes bar even if foo doesn't also obsolete bar. If I'm right, we could get rid of all of these extra obsoletes, making it much easier (more packages to be changed, but a simpler test to lint for, and no judgement calls to be made). If I'm wrong... well, then never mind.
