Bug 701456

Summary: yum allows self-conflicting packages, while rpm does not
Product: [Fedora] Fedora Reporter: Garrett Holmstrom <gholms>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: ffesti, james.antill, jnovy, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-12 09:27:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of the "yum install" command given in the bug description none

Description Garrett Holmstrom 2011-05-02 21:57:00 UTC 
Created attachment 496387 [details]
Output of the "yum install" command given in the bug description

Description of problem:
When a package Provides and Conflicts with the same thing, rpm refuses to install it, but yum is perfectly fine with creating a transaction with such a package.  Which tool has the correct behavior?

Version-Release number of selected component (if applicable):
rpm-4.8.1-5.fc14.x86_64
yum-3.2.28-5.fc14.noarch

How reproducible:
Always

Steps to Reproduce:
``yum -d5 --nogpg install http://homepages.spa.umn.edu/~holms/selfconflict-0-1.fc14.noarch.rpm''
  
Actual results:
Yum creates a transaction that installs the self-conflicting package and hands it to rpm, which rejects it due to the conflict.  (See attached yum output)

Expected results:
yum and rpm agree on whether to reject or allow the transaction

Additional info:
The package I used for testing is here:
http://homepages.spa.umn.edu/~holms/selfconflict-0-1.fc14.noarch.rpm
http://homepages.spa.umn.edu/~holms/selfconflict.spec
Comment 1 Garrett Holmstrom 2011-05-02 21:59:51 UTC 
*** Bug 701452 has been marked as a duplicate of this bug. ***
Comment 2 James Antill 2011-05-02 22:12:40 UTC 
 This is explicit in yum's code, where we do:

                (r, f, v) = conflict
                for conflicting_po in self.tsInfo.getProvides(r, f, v):
                    if conflicting_po.pkgtup[0] == po.pkgtup[0] and conflicting_po.pkgtup[2:] == po.pkgtup[2:]:
                        continue

...and it seems to have come from this commit:

commit 340132409a802dbc172023c064d82d371c2d8e17
Author: Florian Festi <ffesti>
Date:   Fri Jul 13 12:22:50 2007 +0200

    New conflict check implementation using new search API, fixes rh#245707

...although, personally, I think it's the obviously correct behaviour (as conflicting with yourself is not useful).
Comment 3 Panu Matilainen 2011-05-03 05:39:27 UTC 
rpm >= 4.9.0 allows self-conflicting packages, older versions do not (although backporting to 4.8.x remains a possibility). One potential use-case for self-conflicts is "singleton" alternatives, see http://lists.rpm.org/pipermail/rpm-maint/2010-April/002719.html
Comment 4 Panu Matilainen 2011-05-12 09:27:13 UTC 
This is fixed in F15 but no immediate plans on fixing it for older releases -> closing NEXTRELEASE.