Bug 993988 - dnf: deletes local RPMs of dependencies during installation
Summary: dnf: deletes local RPMs of dependencies during installation
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Honza Silhan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-06 13:36 UTC by Stanislav Ochotnicky
Modified: 2013-10-18 13:19 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-10-18 13:19:06 UTC
Type: Bug
Embargoed:


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 13:36 UTC, Stanislav Ochotnicky
no flags Details

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.


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