Description of problem: rpmlint fails to catch bad error Version-Release number of selected component (if applicable): rpmlint-0.83-1.el5.noarch.rpm How reproducible: Always Steps to Reproduce: If a package in a Yum repo obsoletes itself, instead of throwing an error, yum churns for a long time before finally giving up with "recursion limit exceeded" It would be nice if it instead reported an error about the broken package For example, you have foo-1.0-1.noarch.rpm and then you have foo-1.0-2.noarch.rpm which has Obsoletes: 1.0-1 Name: foo Provides: foo Obsoletes: foo RPM happily created it and we put into our Yum repo, but then yum started getting this recursion error rpmlint doesn't seem to flag it...all we get is: unversioned-explicit-provides unversioned-explicit-obsoletes mixed-use-of-spaces-and-tabs Actual results: rpmlint doesn't seem to flag the package Expected results: As a first line of defense rpmlint should catch a problem like this. Additional info: This was done wit the current rpmlint package from EPEL. Will the newer versions of rpmlint currently in fedora (version .84) have fixes for this sort of thing? If so, can we get rpmlint update in EPEL? Thanks.
At the first glance, there are a couple of problems here: a) the Provides and Obsoletes that you have mentioned have absolutely no reason to exist in the spec: rpmbuild will automatically add exactly what is needed. In your case you have literally trashed the version checker. b) as of rpmlint catching the error... it does warn you with the two "unversioned-explicit-*" messages. Which unfortunately you have decided to ignore. The behavior the you have seen is exactly the reason why unversioned obsoletes and provides are banned from Fedora. The new version of rpmlint is in EL-5 CVS, you can download it from there and do a local build if you want. I did not yet do it because I am waiting for more echo from the Fedora branches. I have forwarded your problem to Ville who is way more informed than me about rpmlint (I am just the packaging monkey here), let's see what does he have to say.
Created attachment 316202 [details] Example specfile I don't think there's anything in rpmlint 0.84 that would have any effect on this. But catching self-obsoletion packaging issues is something that rpmlint should do better; I'd like to leave this bug open as a reminder to look into it later. However, in a case you describe, rpmlint should have already emitted the obsolete-on-name error which is related to this issue. It does for me with 0.83-1.el5 for binary packages created from the attached foo.spec.
Good Day, Is this something we can look at fixing in the near future? - James
Note that rpmlib always avoids self-obsoleting packages. There is no reason why rpmlint needs to detect and warn about the issue, nor is there any "self obsoleteing" reason that Provides: foo Obsoletes: foo should be forbidden. I suspect that we can all agree that self-obsoleting packages can never be installed, and so make no sense whatsoever. Which is why rpmlib, not rpmlint, is the place to prevent.
Re comment #1: There is a usage case for co-existent Provides: foo Obsoletes: foo (I'll ignore the versioning issues for simplicity) when a package is renamed, but also is a legacy substitute, for a package. The Provides: foo satisfies assertions against the older name, while Obsoletes: foo is a hint used by yum (and up2date) for discovering that there is a package renaming involved. The two dependencies have different contexts of interpretation.
Even if rpm itself sometime starts to prevent this, we'll continue to live with other old and new tools that have issues with self-obsoleting packages, so a check has been added in upstream svn and will probably be in rpmlint >= 0.88.
Oops, this was an EPEL bug, reverting status to NEW and leaving up to Manuel and Thorsten to decide what to do about it.
re comment #6: RPM has _ALWAYS_ prevented self-obsoleting packages because self-obsoleting packages can _NEVER_ be installed. And if there is a reproducer where self-obsoleting packages are permitted in RPM, that is _CLEARLY_ a bug in RPM, not an RFE for rpmlint.
Created attachment 348826 [details] Another example specfile rpm (4.6.1 on Fedora 10) does not prevent building a package from this specfile, does not prevent installing the resulting binary package, and the Provides and Obsoletes do end up in the package's headers. Perhaps you meant some other kind of self obsoletion but this is what I gather this bug (and self obsoletion generally in packaging context, at least to me) is about, and this is what the newly added rpmlint check is intended to check against.
rpmlint-0.89-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/rpmlint-0.89-1.fc11
rpmlint-0.89-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rpmlint-0.89-1.fc10
SO we've moved beyond self-obsoleting semantics into the world of Hey, this doesn't make any sense?!? Note that rpmlint cannot define what is sensible (or not) for perceived flaws like (ignoring versions for simplicity) Name: foo Obsoletes: foo For starters, its unclear exactly what "foo" represents. And even if Obsoletes: foo is present in *.rpm (i.e. rpmbuild does not fail, and rpm install/upgrade succeeds), there are no harmful effects whatsoever (because the Obsoletes: is _NEVER_ applied to the package that carries the directive). And there's a huge class of possible *.spec defects like Name: foo Provides: bar Obsoletes: bar that rpmlint simply cannot determine whether correct (or not). So you wish rpmlint to explicitly point out that an Obsoletes: is unnecessary whan many many Obsoletes: currently carried in *.rpm packages often are "unnecessary".
rpmlint-0.90-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/rpmlint-0.90-1.fc11
rpmlint-0.90-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rpmlint-0.90-1.fc10
rpmlint-0.90-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
rpmlint-0.90-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
rpmlint-0.91 has been pushed to EPEL-5 stable and now warns on unversioned obsoletes/provides. # rpmlint test.spec test.spec:11: W: unversioned-explicit-obsoletes foo test.spec:14: W: unversioned-explicit-provides bar test.spec:15: W: unversioned-explicit-obsoletes bar 0 packages and 1 specfiles checked; 0 errors, 3 warnings.