Bug 993988

Summary: dnf: deletes local RPMs of dependencies during installation
Product: [Fedora] Fedora Reporter: Stanislav Ochotnicky <sochotni>
Component: dnfAssignee: Honza Silhan <jsilhan>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: akozumpl, jsilhan, pnemade
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: 2013-10-18 13:19:06 UTC Type: Bug
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
tarball with two spec files and generated repository that can be used to reproduce easily none

Description Stanislav Ochotnicky 2013-08-06 13:36:00 UTC
Created attachment 783338 [details]
tarball with two spec files and generated repository that can be used to reproduce easily

Description of problem:
When installing local RPM a.rpm that requires b.rpm from some repository dnf will try to remove b.rpm after installation (this will usually fail with warning between "installing" and "verification" phases, but succeed if repository uses local file:/// URL). 

Steps to reproduce:
1. Build 2 rpms: a.rpm and b.rpm (where a has requires on b)
2. Create local repository (createrepo) from these rpms
3. Run "dnf install /path/to/a.rpm"
4. During installation, b.rpm will be removed from local repository


Version-Release number of selected component (if applicable):
dnf-0.2.23-1.git50db212.fc18.noarch

Notably latest F20 version (dnf-0.3.10-1.giteb9dddb.fc20.noarch) doesn't delete the rpm.

Comment 1 Ales Kozumplik 2013-08-07 08:39:35 UTC
To recap our discussion with Stanislav on IRC yesterday:

This only exhibits in 0.2.x versions on DNF (F18) and is not reproducible in 0.3.x versions (F19 and the current rawhide). It seems the issue went away with the transaction accounting overhaul, particularly the refactoring patch 21eb2e5029f29ad22e7950993dc22befc3a5ae66 is what fixed this.

Backporting the transaction accounting changes as a whole or rebasing DNF in f18 is not attainable, but cherry picking for this particular case should be. Leaving this open for now.

Comment 2 Honza Silhan 2013-10-18 13:19:06 UTC
This bug has been fixed in the upstream. We don't plan to fix it for F18.