Bug 905209 - [kernel] missing upgrades for the kernel package with plain 'dnf update'
Summary: [kernel] missing upgrades for the kernel package with plain 'dnf update'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libsolv
Version: 18
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 871892 912165
TreeView+ depends on / blocked
 
Reported: 2013-01-28 20:57 UTC by Gerald Cox
Modified: 2014-09-30 23:41 UTC (History)
8 users (show)

Fixed In Version: libsolv-0.3.0-3.git7399ad1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-28 02:23:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Gerald Cox 2013-01-28 20:57:31 UTC
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:

Comment 1 Ales Kozumplik 2013-01-29 07:24:59 UTC
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.

Comment 2 Cristian Ciupitu 2013-02-27 11:53:48 UTC
The same happened to me with dnf-0.2.21-1.git050524e.fc18.noarch.

Comment 3 Susi Lehtola 2013-04-05 10:10:39 UTC
Same here with dnf-0.2.22-1.git97180b8.fc18.noarch. The odd thing is that dnf distro-sync would install the newest kernel.

Comment 4 Karel Volný 2013-05-07 12:45:03 UTC
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

Comment 5 Ales Kozumplik 2013-05-14 15:11:02 UTC
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.)

Comment 6 Michael Schröder 2013-05-14 15:35:07 UTC
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.

Comment 7 Michael Schröder 2013-05-14 15:40:25 UTC
(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 ;-) )

Comment 8 Ales Kozumplik 2013-05-15 06:47:50 UTC
> 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:)

Comment 9 Michael Schröder 2013-05-15 10:07:37 UTC
Hopefully fixed with commit #8aaaf8c2

Comment 10 Ales Kozumplik 2013-05-15 12:22:45 UTC
(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)

Comment 11 Michael Schröder 2013-05-15 14:31:05 UTC
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...

Comment 12 Michael Schröder 2013-05-15 14:50:08 UTC
Please try commit #b2ed457

Comment 13 Ales Kozumplik 2013-05-16 07:04:12 UTC
Works for my cases now, thanks:)

Comment 14 Ales Kozumplik 2013-05-16 08:04:27 UTC
In Fedora, this is fixed in libsolv-0.3.0-3, both rawhide and eventually F19.

Comment 15 Fedora Update System 2013-05-16 08:45:59 UTC
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

Comment 16 Susi Lehtola 2013-05-16 09:03:26 UTC
(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?

Comment 17 Ales Kozumplik 2013-05-16 09:25:07 UTC
(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.

Comment 18 Fedora Update System 2013-05-16 17:21:26 UTC
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).

Comment 19 Fedora Update System 2013-05-28 02:23:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.