Red Hat Bugzilla – Bug 461610
rpmlint fails to catch bad error
Last modified: 2010-09-27 07:53:31 EDT
Description of problem:
rpmlint fails to catch bad error
Version-Release number of selected component (if applicable):
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
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:
rpmlint doesn't seem to flag the package
As a first line of defense rpmlint should catch a problem like this.
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?
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]
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?
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
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
(I'll ignore the versioning issues for simplicity)
when a package is renamed, but also is a legacy substitute,
for a package.
satisfies assertions against the older name, while
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.
rpmlint-0.89-1.fc10 has been submitted as an update for Fedora 10.
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)
For starters, its unclear exactly what "foo" represents. And even if
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
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
rpmlint-0.90-1.fc11 has been submitted as an update for Fedora 11.
rpmlint-0.90-1.fc10 has been submitted as an update for Fedora 10.
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.