Description of problem: DNF keeps packages with broken scriptlets installed, although it claims they were removed: ~~~ $ LANG=C.utf-8 sudo dnf remove vagrant-adbinfo Dependencies resolved. ======================================================================== Package Arch Version Repository Size ======================================================================== Removing: vagrant-adbinfo noarch 0.0.9-4.fc24 @rawhide 24 k Transaction Summary ======================================================================== Remove 1 Package Installed size: 24 k Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- vagrant/plugin/manager (LoadError) from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require' from -e:3:in `<main>' error: %preun(vagrant-adbinfo-0.0.9-4.fc24.noarch) scriptlet failed, exit status 1 Error in PREUN scriptlet in rpm package vagrant-adbinfo Error in PREUN scriptlet in rpm package vagrant-adbinfo vagrant-adbinfo-0.0.9-4.fc24.noarch was supposed to be removed but is not! Verifying : vagrant-adbinfo-0.0.9-4.fc24.noarch 1/1 Removed: vagrant-adbinfo.noarch 0.0.9-4.fc24 Complete! $ rpm -q vagrant-adbinfo vagrant-adbinfo-0.0.9-4.fc24.noarch ~~~ Interestingly enough, if the package had some dependencies, they would be removed. Also, there is no way (AFAIK) to remove such package via DNF ... Version-Release number of selected component (if applicable): $ rpm -q dnf dnf-2.0.0-2.fc26.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Package with broken scriptlet is kept installed, while it is reported to be removed. Also its dependencies are possibly removed. There is noway how to remove such package via DNF. Expected results: The issue should be properly reported, the transaction possibly aborted. But the package should be definitely possible to remove ... Additional info: Actually, it happened to me that by series of install/remove I got 4 copies of this package on my system reported by RPM.
we will investigate why DNF does not report the package was not removed correctly. The DNF return code should be checked as well.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I have to ask rpm team, how to solve a problem. Simply rpm refuse to remove the file and even it do not report removal as fail. It can be reproduce: 1. dnf install https://kojipkgs.fedoraproject.org//packages/vagrant-adbinfo/0.0.9/4.fc24/noarch/vagrant-adbinfo-doc-0.0.9-4.fc24.noarch.rpm 2. rpm -e --nodeps $(dnf repoquery --installed -q rubygem*) 3. rpm -e vagrant-adbinfo In this case rpm refuse to remove package with return code 255. We really cannot do much if rpm cannot handle it.
%preun scriptlets have the power to stop a package from being removed, this is expected behavior. Yes, typos fixed in the next release and all. "rpm -e --noscripts vagrant-adbinfo" to get around it. IIRC yum had some switch to do the same. As for the verifying step showing all okay I dunno what yum (and now dnf due to the inheritance) do there, it always seemed like a strange addition to me. Instead of filling the screen with redundant goo that's not even accurate (as witnessed here), it could ask rpm whether a transaction element failed (te.Failed()) and only report the failed ones if there were any, or something like that.
Thanks Panu for info. But to fix problem we need an assistance from RPM. In this case we run: errors = rpm.transaction.TransactionSet.run() But errors is 0. then we tests (code dnf.base lines 796-833) # ts.run() exit codes are, hmm, "creative": None means all ok, empty # list means some errors happened in the transaction and non-empty # list that there were errors preventing the ts from starting... if errors is None: pass elif len(errors) == 0: # this is a particularly tricky case happening also when rpm failed # to obtain the transaction lock. We can only try to see if a # particular element failed and if not, decide that is the # case. if len([el for el in self._ts if el.Failed()]) > 0: errstring = _('Warning: scriptlet or other non-fatal errors ' 'occurred during transaction.') logger.debug(errstring) and el.Failed() == 1 but we recognize it as soft problem. Please can you provide detailed information how we should handle the returns from rpm and their combinations? Thanks a lot for your help.
Well that's more "creativity" in this area. Chasing down the origins of that el.Failed() and its interpretation comes to this: commit 543a95d8859377530270a7515002d099a87abfd7 Author: Ales Kozumplik <akozumpl> Date: Tue Apr 17 13:58:42 2012 +0200 better handling of the no-root situtation. ...for which checking te.Failed() seems bizarre. At any rate, te.Failed() returning true certainly signifies a hard error and is what rpm itself uses to track failures within transaction.
Thanks for help. I created a pull request that should solve the problem with marking unremoved packages as removed: https://github.com/rpm-software-management/dnf/pull/780 . To remove packages with broken scriplets it is possible to use "dnf remove --setopt=tsflags=noscripts <package>" .
dnf-plugins-core-2.0.0-1.fc26 libdnf-0.8.2-1.fc26 dnf-2.4.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4e95959f0d
dnf-2.4.0-1.fc26 dnf-plugins-core-2.0.0-1.fc26 dnf-plugins-extras-2.0.0-1.fc26 libdnf-0.8.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4e95959f0d
dnf-2.4.0-1.fc26, dnf-plugins-core-2.0.0-1.fc26, dnf-plugins-extras-2.0.0-1.fc26, libdnf-0.8.2-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-4e95959f0d
dnf-2.4.0-1.fc26, dnf-plugins-core-2.0.0-1.fc26, dnf-plugins-extras-2.0.0-1.fc26, libdnf-0.8.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.