Bug 993988 - dnf: deletes local RPMs of dependencies during installation
dnf: deletes local RPMs of dependencies during installation
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Honza Silhan
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-06 09:36 EDT by Stanislav Ochotnicky
Modified: 2013-10-18 09:19 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-18 09:19:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tarball with two spec files and generated repository that can be used to reproduce easily (7.29 KB, application/x-xz)
2013-08-06 09:36 EDT, Stanislav Ochotnicky
no flags Details

  None (edit)
Description Stanislav Ochotnicky 2013-08-06 09:36:00 EDT
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):

Notably latest F20 version (dnf-0.3.10-1.giteb9dddb.fc20.noarch) doesn't delete the rpm.
Comment 1 Ales Kozumplik 2013-08-07 04:39:35 EDT
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 09:19:06 EDT
This bug has been fixed in the upstream. We don't plan to fix it for F18.

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