Description of problem: # dnf --exclude dmidecode remove puppet Failed to set locale, defaulting to C Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: dmidecode x86_64 1:2.12-9.fc23 @System 203 k facter x86_64 2.4.3-1.fc23 @System 273 k hiera noarch 1.3.4-4.fc24 @System 54 k libselinux-ruby x86_64 2.4-3.fc24 @System 223 k puppet noarch 4.2.1-1.fc24 @System 4.2 M ruby x86_64 2.2.3-44.fc24 @System 69 k ruby-augeas x86_64 0.5.0-7.fc23 @System 52 k ruby-irb noarch 2.2.3-44.fc24 @System 162 k ruby-libs x86_64 2.2.3-44.fc24 @System 10 M ruby-shadow x86_64 1.4.1-27.fc23 @System 21 k rubygem-bigdecimal x86_64 1.2.6-44.fc24 @System 88 k rubygem-io-console x86_64 0.4.3-44.fc24 @System 20 k rubygem-json x86_64 1.8.2-101.fc23 @System 149 k rubygem-pathspec noarch 0.0.2-3.fc23 @System 24 k rubygem-psych x86_64 2.0.8-44.fc24 @System 120 k rubygem-rdoc noarch 4.2.0-44.fc24 @System 1.7 M rubygem-rgen noarch 0.7.0-1.fc23 @System 310 k rubygem-safe_yaml noarch 1.0.4-2.fc23 @System 32 k rubygems noarch 2.4.8-100.fc24 @System 898 k rubypick noarch 1.1.1-4.fc24 @System 4.4 k virt-what x86_64 1.15-2.fc23 @System 41 k Transaction Summary ================================================================================ Remove 21 Packages Installed size: 19 M Is this ok [y/N]: Operation aborted. Version-Release number of selected component (if applicable): libsolv-0.6.11-3.git1f9abfb.fc24.x86_64 hawkey-0.6.0-1.fc24.x86_64 dnf-1.1.1-1.fc24.noarch
well, maybe dnf could print error that package puppet cannot be uninstalled because dmidecode cannot be removed. FYI puppet has dmidecode dependency (`dnf repoquery --tree --requires puppet | grep dmidecode`)
I really don't understand why I can't remove puppet without removing dmidecode as well.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Hard dependencies: dnf --setopt=strict=false erase python3-devel --exclude python3-tools: empty transaction dnf --setopt=strict=true erase python3-devel --exclude python3-tools: error due to hard dependency Soft dependencies: whatever set to strict, exclude package from removal I think it should be implemented this way.
*** Bug 1222220 has been marked as a duplicate of this bug. ***
Not sure what is the "--setopt=strict=true" supposed to do, but the "-x" does not work as expected :( ~~~ $ LANG=C.UTF-8 sudo dnf --setopt=strict=true remove scl-utils -x environment-modules Dependencies resolved. =============================================================================== Package Arch Version Repository Size =============================================================================== Removing: scl-utils x86_64 1:2.0.1-14.fc27 @updates-testing 56 k Removing unused dependencies: environment-modules x86_64 3.2.10-21.fc27 @updates-testing 223 k tcl x86_64 1:8.6.6-4.fc27 @updates-testing 4.1 M Transaction Summary =============================================================================== Remove 3 Packages Freed space: 4.3 M Is this ok [y/N]: ^COperation aborted. ~~~
"$ sudo dnf --setopt=clean_requirements_on_remove=false remove scl-utils" helped for my case ...
There is one additional mechanism how to prevent of removal unused dependency. The dependency can be marked as user installed. Like in Comment 7. $ sudo dnf mark install environment-modules # It marks package environment-modules as user installed permanently # It can be reverted by ``sudo dnf mark remove environment-modules`` that marks package environment-modules as dependency. $ sudo dnf remove scl-utils Additional notes: ``--setopt=strict=true`` doesn't have any effect for remove command ``--setopt=clean_requirements_on_remove=false`` is equivalent to ``--noautoremove`` option (disable of removal of unused dependencies dnf-2.6.4) Therefore: $ sudo dnf --noautoremove remove scl-utils # will not remove any unused dependency Because the problem can be easily solved by present dnf options and command I think that the bug report can be closed. Please if anyone will feel, that this is insufficient or for example the documentation can be enhanced, please don't hesitate to reopen the bug report.
I am sorry, but what you suggest is neither easy nor user friendly IMHO. If I want to remove some package from transaction, then I go for -x option and it doesn't really matter which action it is, I expect it to work. Also, please note that environment-modules and scl-utils, both were installed on my computer via Anaconda: ~~~ $ sudo dnf history info 1 | grep environment Instalovat environment-modules-3.2.10-21.fc26.x86_64 @anaconda/26 $ sudo dnf history info 1 | grep scl Instalovat scl-utils-1:2.0.1-12.fc26.x86_64 @anaconda/26 ~~~ So I don't feel I should mark them as user installed.
Ok Vit, then please can you provide what behavior you expect in following situations? TestA requires TestB, TestC 1. # dnf remove TestA -x TestC 2. # dnf remove TestC -x TestA 3 # dnf remove TestA (but in dnf.conf exclude=TestC) 4 # dnf remove TestC (but in dnf.conf exclude=TestA) 5 # dnf remove TestA --setopt=exclude=TestC 6 # dnf remove TestC --setopt=exclude=TestA Also I want to ask you why you want to kept environment-modules and why you don't want to mark it as user installed? It will not change the history, it only marks the package with reason user. This information is only used to prevent removal as unused dependency. I want to mention, that the similar behavior is also used in debian. In general there is problem with excludes, because they are often forgotten in dnf.conf and suddenly user wonder, why dnf works differently. Excludes are also widely used by versionlock plugin or by modularity, therefore any changes here can have wide consequence effects and this is the main reason why I close the bug report. Thanks a lot for communication.
First of all, it would be nice if DNF mentioned excluded packages, which would be under normal conditions part of the transaction, somewhere in the summary of the action, since as you pointed out, there are several places where the package can be excluded. (In reply to Jaroslav Mracek from comment #11) > Ok Vit, then please can you provide what behavior you expect in following > situations? > > TestA requires TestB, TestC > > 1. # dnf remove TestA -x TestC This removes TestA and keeps TestC untouched. > 2. # dnf remove TestC -x TestA This fails, since TestA depends on TestC > 3 # dnf remove TestA (but in dnf.conf exclude=TestC) This removes TestA and keeps TestC. > 4 # dnf remove TestC (but in dnf.conf exclude=TestA) This fails, since TestA depends on TestC > 5 # dnf remove TestA --setopt=exclude=TestC This removes TestA and keeps TestC. > 6 # dnf remove TestC --setopt=exclude=TestA This fails, since TestA depends on TestC > Also I want to ask you why you want to kept environment-modules and why you > don't want to mark it as user installed? I have not installed it. It was installed by default installation, so why should I change anything? And actually I have never marked the package as user installed (or I don't remember and don't know how to check) and the "autoremove" is not trying to uninstall the package. So again, why I should change anything?
I created a patch for libsolv (https://github.com/openSUSE/libsolv/pull/225) and libdnf (https://github.com/rpm-software-management/libdnf/pull/324) that should provide the behavior.
dnf-plugins-extras-2.0.3-1.fc27 dnf-plugins-core-2.1.4-1.fc27 dnf-2.7.2-1.fc27 libdnf-0.10.1-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-faf235c683
dnf-plugins-extras-2.0.3-1.fc26 dnf-plugins-core-2.1.4-1.fc26 dnf-2.7.2-1.fc26 libdnf-0.10.1-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-70a8618065
dnf-2.7.2-1.fc26, dnf-plugins-core-2.1.4-1.fc26, dnf-plugins-extras-2.0.3-1.fc26, libdnf-0.10.1-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-70a8618065
dnf-2.7.2-1.fc27, dnf-plugins-core-2.1.4-1.fc27, dnf-plugins-extras-2.0.3-1.fc27, libdnf-0.10.1-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-faf235c683
dnf-2.7.2-1.fc27, dnf-plugins-core-2.1.4-1.fc27, dnf-plugins-extras-2.0.3-1.fc27, libdnf-0.10.1-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
dnf-2.7.2-1.fc26, dnf-plugins-core-2.1.4-1.fc26, dnf-plugins-extras-2.0.3-1.fc26, libdnf-0.10.1-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.