Description of problem: When using "dnf upgrade" some packages are missed even though an upgrade is available. For example, I issue the command: "dnf upgrade" - system responds: Setting up Update Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Nothing to do If I then issue: "yum upgrade" - system responds: Resolving Dependencies --> Running transaction check ---> Package kernel-devel.x86_64 0:3.7.4-204.fc18 will be installed --> Finished Dependency Resolution Dependencies Resolved Curiously, if I enter: "dnf upgrade kernel*" - system responds: Setting up Update Process Resolving Dependencies --> Starting dependency resolution ---> Package kernel-devel.x86_64 3.7.4-204.fc18 will be installed --> Finished dependency resolution Dependencies Resolved Version-Release number of selected component (if applicable): How reproducible: Issue "dnf upgrade" command Steps to Reproduce: 1. Issue "dnf upgrade" command Actual results: System responds: Setting up Update Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Nothing to do Expected results: System responds: Setting up Update Process Resolving Dependencies --> Starting dependency resolution ---> Package kernel-devel.x86_64 3.7.4-204.fc18 will be installed --> Finished dependency resolution Additional info:
Thanks for the report. This is related to bug 880524. In short, there are things about managing the kernel package that dnf does not do yet they way yum does.
The same happened to me with dnf-0.2.21-1.git050524e.fc18.noarch.
Same here with dnf-0.2.22-1.git97180b8.fc18.noarch. The odd thing is that dnf distro-sync would install the newest kernel.
still problem with dnf-0.2.23-1.git50db212.fc18.noarch [root@kvolny ~]# yum upgrade Zavedené moduly: auto-update-debuginfo, langpacks, presto, refresh-packagekit Řešení závislostí... --> Kontrola transakce spuštěna ---> Balíček kernel.x86_64 0:3.8.11-200.fc18 bude instalován --> Řešení závislostí dokončeno --> Kontrola transakce spuštěna ---> Balíček kernel.x86_64 0:3.8.7-201.fc18 bude smazán --> Řešení závislostí dokončeno Závislosti vyřešeny. =============================================================================================================================================================================================================== Package Arch Verze Repozitář Vel. =============================================================================================================================================================================================================== Instalování: kernel x86_64 3.8.11-200.fc18 updates 28 M Odstraňuje se: kernel x86_64 3.8.7-201.fc18 @updates 122 M Shrnutí transakce =============================================================================================================================================================================================================== Instalovat 1 Package Remove 1 Package Celková velikost ke stahování: 28 M V pořádku [a/N]: N Ukončeno na příkaz uživatele Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2013-05-07.14-44.FPgcjk.yumtx [root@kvolny ~]# dnf upgrade Příprava průběhu aktualizace Řešení závislostí... --> Starting dependency resolution --> Finished dependency resolution Není co dělat
Hello Michael, I have a libsolv question. Suppose the following failing testcase: repo system 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 25 1 x86_64 repo available 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 31 1 x86_64 system x86_64 rpm system job multiversion name c job update all packages result transaction,problems <inline> #>install c-31-1.x86_64@available My question is: is this a bug or is that how you'd envision multiversion should work (i.e. I can workaround it in DNF transaction by manually pouring all found multiversion packages of higher version as installs into the job---should I go for that?). (Also sorry, I know it was us who introduced NOOBSOLETES. Just kindof unsure what to do with it now.)
It's a bug, of course. It works if the installed package is still available in one of the repos, that's why nobody noticed before. I'll fix it tomorrow.
(NOOBSOLETES? I added that for SUSE kernel packages, it kind of reflected what rpm did at that time. Then Panu changed that rpm still looks at obsoletes and you guys sent me a patch that added SOLVER_FLAG_KEEP_EXPLICIT_OBSOLETES. Which was not the right way to deal with the rpm change, as the transaction doesn't know the solver flags, so I moved the flag into the pool. It's now called POOL_FLAG_NOOBSOLETESMULTIVERSION, so the default has changed to reflect the rpm default. What a mess ;-) )
> It's a bug, of course. It works if the installed package is still available > in one of the repos, that's why nobody noticed before. I'll fix it tomorrow. Thank you! > (NOOBSOLETES? I added that for SUSE kernel packages, it kind of reflected > what rpm did at that time. > Then Panu changed that rpm still looks at obsoletes and you guys sent me a > patch that added SOLVER_FLAG_KEEP_EXPLICIT_OBSOLETES. Which was not the > right way to deal with the rpm change, as the transaction doesn't know the > solver flags, so I moved the flag into the pool. It's now called > POOL_FLAG_NOOBSOLETESMULTIVERSION, so the default has changed to reflect the > rpm default. Good, I take it once I rebase libsolv in Fedora to post-982e0fa3 I don't have to set the SOLVER_FLAG_KEEP_EXPLICIT_OBSOLETES flag anymore. > What a mess ;-) ) But it could be worse:)
Hopefully fixed with commit #8aaaf8c2
(In reply to comment #9) > Hopefully fixed with commit #8aaaf8c2 the basic case now works but the following fails: repo system 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 25 1 x86_64 #>=Pkg: d 1 1 x86_64 repo available 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 31 1 x86_64 #>=Obs: d system x86_64 rpm system solverflags keepexplicitobsoletes job multiversion provides c job update all packages result transaction,problems <inline> #>install c-31-1.x86_64@available (again, wouldn't swear this is a bug, yet keepexplicitobsoletes should just cause 'd' to be really obsoleted, instead of skipping the install altogether in my opinion)
Yes, that seems to be missing in the keepexplicitobsoletes patch. c-31 is not listed in the update rule for d, so the solver doesn't know it is an update candidate. Fixing...
Please try commit #b2ed457
Works for my cases now, thanks:)
In Fedora, this is fixed in libsolv-0.3.0-3, both rawhide and eventually F19.
libsolv-0.3.0-3.git7399ad1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libsolv-0.3.0-3.git7399ad1.fc19
(In reply to comment #14) > In Fedora, this is fixed in libsolv-0.3.0-3, both rawhide and eventually F19. No hope of getting this in F18?
(In reply to comment #16) > (In reply to comment #14) > > In Fedora, this is fixed in libsolv-0.3.0-3, both rawhide and eventually F19. > > No hope of getting this in F18? No, sorry.
Package libsolv-0.3.0-3.git7399ad1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libsolv-0.3.0-3.git7399ad1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8329/libsolv-0.3.0-3.git7399ad1.fc19 then log in and leave karma (feedback).
libsolv-0.3.0-3.git7399ad1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.