Bug 905209

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.