Bug 461610 - rpmlint fails to catch bad error
Summary: rpmlint fails to catch bad error
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: rpmlint
Version: el5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: manuel wolfshant
QA Contact: Fedora Extras Quality Assurance
Whiteboard: ActualBug
Depends On:
TreeView+ depends on / blocked
Reported: 2008-09-09 13:38 UTC by Kent Baxley
Modified: 2018-11-14 18:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-09-27 11:53:31 UTC

Attachments (Terms of Use)
Example specfile (183 bytes, text/plain)
2008-09-09 15:48 UTC, Ville Skyttä
no flags Details
Another example specfile (622 bytes, text/plain)
2009-06-21 21:42 UTC, Ville Skyttä
no flags Details

Description Kent Baxley 2008-09-09 13:38:22 UTC
Description of problem:
rpmlint fails to catch bad error

Version-Release number of selected component (if applicable):

How reproducible:

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: 

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? 


Comment 1 manuel wolfshant 2008-09-09 14:23:12 UTC
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.

Comment 2 Ville Skyttä 2008-09-09 15:48:53 UTC
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.

Comment 3 James G. Brown III 2009-05-20 19:16:37 UTC
Good Day, Is this something we can look at fixing in the near future?

- James

Comment 4 Jeff Johnson 2009-05-21 16:04:56 UTC
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.

Comment 5 Jeff Johnson 2009-05-21 16:15:40 UTC
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.

   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.

Comment 6 Ville Skyttä 2009-06-21 20:02:07 UTC
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.

Comment 7 Ville Skyttä 2009-06-21 20:04:12 UTC
Oops, this was an EPEL bug, reverting status to NEW and leaving up to Manuel and Thorsten to decide what to do about it.

Comment 8 Jeff Johnson 2009-06-21 20:30:12 UTC
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.

Comment 9 Ville Skyttä 2009-06-21 21:42:41 UTC
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.

Comment 10 Fedora Update System 2009-06-21 22:00:46 UTC
rpmlint-0.89-1.fc11 has been submitted as an update for Fedora 11.

Comment 11 Fedora Update System 2009-06-21 22:02:04 UTC
rpmlint-0.89-1.fc10 has been submitted as an update for Fedora 10.

Comment 12 Jeff Johnson 2009-06-21 22:10:22 UTC
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

Comment 13 Fedora Update System 2009-06-29 15:46:04 UTC
rpmlint-0.90-1.fc11 has been submitted as an update for Fedora 11.

Comment 14 Fedora Update System 2009-06-29 15:48:25 UTC
rpmlint-0.90-1.fc10 has been submitted as an update for Fedora 10.

Comment 15 Fedora Update System 2009-07-16 07:26:41 UTC
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.

Comment 16 Fedora Update System 2009-07-16 07:29:18 UTC
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.

Comment 19 Mark Chappell 2010-09-27 11:53:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.