Bug 1304887

Summary: dnf always installs newest version, ignoring excludes
Product: [Fedora] Fedora Reporter: Jef Oliver <jef.oliver>
Component: dnfAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 23CC: jef.oliver, jmracek, jsilhan, mluscon, packaging-team-maint, pnemade, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-15 14:30:09 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
repo files for DNF none

Description Jef Oliver 2016-02-04 22:04:56 UTC 
Description of problem:
When installing a package, or when a package is installed as a dependency, dnf always installs the latest available version, ignoring excludes. This was found using the installroot option.

Example:
A kernel repository is added to Fedora containing kernel packages. The repository sections for [fedora] and [fedora-updates] have exclude=kernel* added to them. The kernel is available in the separate repository. Despite the exclude lines being in place and the kernel being available in the second repo, dnf sees that upstream has a newer kernel version and uses it.

This example works fine using yum on Fedora 21.


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

How reproducible:
Every time

Steps to Reproduce:
1. Create a new repository with a package that is older than upstream availability.
2. Create an installroot location, ie a chroot install. (rpm --initdb /some/path/db, dfn --installroot install fedora-release fedora-repo)
3. Add new repository to installroot
4. dnf --installroot=/some/path install package_in_new_repo

Actual results:
The newer, upstream, excluded package is used.

Expected results:
The newer, upstream, excluded package should be ignored, and the older package in the unexcluded repo should be installed.
Comment 1 Jaroslav Mracek 2016-02-08 13:01:51 UTC 
Please could you provide some additional information. Could you send us both dnf.conf file from host and --installroot with exact marked locations where each file was located.
Comment 2 Jef Oliver 2016-02-09 04:24:28 UTC 
Created attachment 1122338 [details]
repo files for DNF

dnf.conf files are unmodified. I only copy repo files into place.

I create a new root directory.
/tmp/XN0TDJIB3MBGLD9L/image/root

Download fedora-release and fedora-repos rpms and install

rpm --quiet --root /tmp/XN0TDJIB3MBGLD9L/image/root --initdb
rpm --quiet --root /tmp/XN0TDJIB3MBGLD9L/image/root -i --nodeps /tmp/XN0TDJIB3MBGLD9L/download/onpss-internal-0.0.2-201602081749.gitdb76a315.fc21.x86_64.rpm /tmp/XN0TDJIB3MBGLD9L/download/fedora-repos-23-1.noarch.rpm /tmp/XN0TDJIB3MBGLD9L
/download/fedora-release-23-1.noarch.rpm

After this, I copy the files in the attachment to /tmp/XN0TDJIB3MBGLD9L/image/root/etc/yum.repos.d/

Then install packages
dnf -q -y --installroot=/tmp/XN0TDJIB3MBGLD9L/image/root --enablerepo=*-daily makecache
dnf -q -y --installroot=/tmp/XN0TDJIB3MBGLD9L/image/root --enablerepo=*-daily install yum yum-utils kernel systemd iproute

If the kernel that is located in my addon kernel repo is older than upstream, dnf seems to ignore my provided kernel and force uses the upstream version. This was not the case using standard yum in Fedora 21.
Comment 3 Jaroslav Mracek 2016-02-15 12:57:41 UTC 
I am going to test your case.
Comment 4 Jaroslav Mracek 2016-02-15 14:30:09 UTC 
Ok I think I have it. The repository are taken from host at the present version of DNF. Your problem will be solved by new version of dnf, where behavior is changed. See pull-request https://github.com/rpm-software-management/dnf/pull/428.
There is also new detailed description in documentation. 
 Thanks for reporting.

*** This bug has been marked as a duplicate of bug 1279185 ***