Red Hat Bugzilla – Bug 1055910
[rfe] includes directive support should work with no excludes defined
Last modified: 2016-04-12 20:35:17 EDT
As this has already been reported by error in #871892 (sorry Ales), I noticed that dnf doesn't uses the includepkgs directive in repositories configuration files (.repo) as yum does. I must indicate that no other directive regarding including or excluding packages are in use in the repositories sections.
For example, while using yum, if I add the following directive in a repository section:
only dnf and yum would be installed/updated/upgraded from that repository. The others packages from that repository wouldn't be taken in account.
While using dnf, there seems that the includepkgs directive is ignored, and all the packages from that repository are taken in account.
What I understood about this directive with yum, is that it includes only the list packages but not all the others, while the exclude directive includes all the packages but not the listed ones. Maybe I'm wrong.
Hope this functionality will be added to dnf in order to make it fully usable and replace yum in mixed repositories environments.
Thanks, yes we will try to take a look before the final release, especially if there is more users requesting this.
Hi Ivana, please take a look at this as your starting bug. I recommend looking at how excludes are implemented in dnf and in hawkey and then just going through the given repo and excluding everything that does not match the pattern.
Don't forget to update the documentation.
I'll be glad to help if you run into issues or questions.
*** Bug 1062872 has been marked as a duplicate of this bug. ***
Also see bug 1099342 comment 10, it's plausible we'll have to change how excludes/includes are implemented in hawkey.
include directive added to dnf.conf. Note: in dnf it's called "include" not "includepkgs" as it's in yum.
This doesn't appear to be working, unless I'm missing something. If I put:
in the repo file, when executing dnf upgrade, the repo is unceremoniously
skipped with the error message:
Warning: failed loading '/etc/yum.repos.d/fedora-updates.repo', skipping.
If I use (which shouldn't work at all):
the statement is just ignored, but the repo is at least accepted for processing.
Here is what I have installed for dnf:
Updated product info.
I installed the following from rawhide and the issue still exists:
Gerald, you're right. includes could be set from `--setopt` option but in config it conflicted with another option. PR which fix this is created.
dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21 has been submitted as an update for Fedora 21.
Package hawkey-0.5.3-2.fc21, dnf-plugins-core-0.1.5-1.fc21, dnf-0.6.4-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hawkey-0.5.3-2.fc21 dnf-plugins-core-0.1.5-1.fc21 dnf-0.6.4-1.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
hawkey-0.5.3-2.fc21, dnf-plugins-core-0.1.5-1.fc21, dnf-0.6.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Sorry for re-opening this bug report.
After upgrading to F-22 (which is using dnf as the default package manager), I just realised that the problem still persist.
The upgrade went well, but the includepkgs directives included in my /etc/yum.repos.d files were ignored while the upgrade process, and then some non-official Fedora packages were upgraded the wrong way. For example, with a remi.repo file before the upgrade like this:
name=Les RPM de remi - Fedora $releasever - $basearch
includepkgs=bluegriffon remi-release libdvdcss
all the php* packages already installed were upgraded to remi's repo ones.
Now that the machine is in this state, I tried to modify the repo file as this (according to the dnf documentation the includepkgs directive was replaced by include and coma separated list):
name=Les RPM de remi - Fedora $releasever - $basearch
in order to revert the php* packages to the official Fedora ones via the distribution-synchronization command of dnf.
But unfortunately, this has failed. Nothing to do is the dnf response.
Maybe I misunderstood the new include and exclude options, and how to set them up in the /etc/yum.repos.d files, but my question is: how to get this working as it was working with yum (see my description in the first post)?
I tried adding the exclude=* directive in the remi-nico section in the remi.repo file, but there seems that it is evaluated globally, and not just for that repository only, because no packages are listed by dnf.
Any comment about this are welcome.
Seeing the same problem. dnf distro-sync wants to pull in packages from remi just after the F22 upgrade.
After a little playing with dnf and /etc/yum.repos.d/*.repo files, there seems that include and exclude directives are not working as old yum includepkgs and exclude directive were.
Actually, with F-22 using include directive in one .repo file, it is not possible to allow exclusively some packages from a repository but all.
Adding the exclude directive left blank (i.e. exclude=) in a .repo file makes dnf globally blind but not "repo specific" (tried dnf check-update and got "nothing to do" while removing exclude blank directive gives some results).
Tell me if I could do something more to try to catch this issue.
Any comments about this are welcome.
Actually, in order to keep F-22 functional (not breaking it with all the packages provided by third-party repositories) with a few of special packages from third-party repositories, one needs to disable all third-party repositories and upgrade manually and explicitly each package for each third-party repository enabling them manually (--enablerepo command line option).
Hope something could be done in order to get old yum usage back in dnf (as dnf is the only solution for F-22).
Sorry for the noise, bt is there any news since comment #13 about this really useful functionality provided by yum and in the way to be available for dnf?
Should we maybe raise this to Fedora 22, as it is still current?
To note why this bug has affected me recently, as this may be a common scenario that will silently cause unexpected package installs.
I have an (upgraded) F22 install. I had the remi repo set up to only "includepkgs= remi-release libdvdcss"
Nothing out of the ordinary until last week, when some php-* packages were added to the remi repo which overwrote the standard Fedora packages -- which is not the behaviour I desire.
I've had to manually downgrade the packages and disable the repo.
Note that I only spotted this as I was using dnf on the command line. I suspect that, if I'd been using gnome software, the packages would have been upgraded to the non-Fedora versions (not desired).
Before last week there was no indication this was a problem, it was just silently continuing to use the repo.
So it seems like a fairly bad downgrade of feature parity, especially in the case of upgraded installations, as it silently puts the installed packages into an unwanted and unexpected state.
Seems a duplicate of 1219867
As yes, this make dnf unusable for now.
I think this bug should be raised to Fedora 22, because Fedora 22 is more affected as dnf is the default package manager, but in Fedora 21 yum is the default.
This bug makes it more difficult to use rpms.remirepo.net only for libdvdcss but prevent accidental updating of other packages which are also in this repo.
any updates on this?
(In reply to Ashesh Kumar Singh from comment #21)
> any updates on this?
Me too, on F23.
Same problem here on RHEL 7.
I installed dnf-0:0.6.4-2.el7.noarch to get used to it (I use fedora on my personal machines).
When using dnf instead of yum, includepkgs (or include) statements in repo files get ignored.
Any news ?
I don't understand why this is marked as "rfe" so with low priority.
IMHO, this is a major "regression" / lack of feature compared to yum.
Just tried the same on my local F23 box...
Using dnf-1.1.5-1.fc23.noarch produces the same unexpected behavior as described.
Do we need to declare this bug upstream ?
Also, this bug is declared for F22 but also happens on F23, does a new bugreport need to be filled or does this one need an update?