Hide Forgot
Description of problem: On x86_64 machine when I install i686 variant of package and will run "dnf upgrade" yum will install x86_64 version of that package as well. I encountered this when I installed Steam, which requires 32 bits packages and I really do not need some 64 bits variants. Version-Release number of selected component (if applicable): dnf-0.3.11-1.git7d717c7.fc19.noarch How reproducible: deterministic Steps to Reproduce: 1. install: tslib-1.0-6.fc19.i686 (or simply latest 32 variant of this package) 2. yum upgrade (nothing to upgrade) 3. dnf upgrade (nothing to upgrade) 4. dnf upgrade --best Actual results: Will install tslib-1.0-6.fc19.x86_64 Expected results: Nothing to upgrade.
Created attachment 788410 [details] debug data of "dnf upgrade --best --debugsolver tslib"
Michael, this boils down to the following: --- repo system 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 25 1 i686 repo available 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 25 1 x86_64 poolflags implicitobsoleteusescolors system x86_64 rpm system job update name c [forcebest] result transaction,problems <inline> #>install c-25-1.x86_64@available --- I even think it's the expected behavior. The question is what can libsolv do here: if not much then I'll just document this as the expected behavior of --best.
Well, c-25-1.x86_64 *is* the best package. It's a bit unfortunate that c-25-1.i686 does not get erased with the "update", though. As to what libsolv can do, you can set the "SOLVER_FLAG_BEST_OBEY_POLICY" flag to make the "best" selection obey update policy rules, i.e. to make the architecture "stick". I didn't make that the default, because then people complain that the "best" package does not get chosen. The idea was to provide a "--best" and a "--really-best" or something ;)
Thanks Michael, the flag to distinguish best/really-best was exactly what I was looking for (yet afraid to ask for it to be added).
Fixed by eb0d437, will be available in hawkey-0.3.17. Thanks for reporting this Miroslav.
dnf-0.4.1-1.git55e6369.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.4.1-1.git55e6369.fc20
Package dnf-0.4.1-1.git55e6369.fc20, librepo-1.1.0-1.fc20, hawkey-0.4.1-1.git6f35513.fc20, libcomps-0.1.3-5.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.4.1-1.git55e6369.fc20 librepo-1.1.0-1.fc20 hawkey-0.4.1-1.git6f35513.fc20 libcomps-0.1.3-5.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16868/librepo-1.1.0-1.fc20,hawkey-0.4.1-1.git6f35513.fc20,libcomps-0.1.3-5.fc20,dnf-0.4.1-1.git55e6369.fc20 then log in and leave karma (feedback).
dnf-0.4.1 has been pushed and superseded. Closing this.