Setting a limit on concurrently installed installonly packages

[kontura]

In dnf we a installonly_limit which is the maximum number of installonly packages allowed to be installed concurrently. Defaults to 3. (We use this logic to ensure it.)

Recently we had a problem where a user tried to install kernel-core only via a provide (kernel-core-uname-r) resulting in a job like:

repo @System 0.0 testtags <inline>
#>=Pkg: kernel 4.18.16 300.fc29 x86_64
#>=Req: kernel-core-uname-r = 4.18.16-300.fc29.x86_64
#>=Req: kernel-modules-uname-r = 4.18.16-300.fc29.x86_64
#>
#>=Pkg: kernel 4.19.15 300.fc29 x86_64
#>=Req: kernel-core-uname-r = 4.19.15-300.fc29.x86_64
#>=Req: kernel-modules-uname-r = 4.19.15-300.fc29.x86_64
#>
#>=Pkg: kernel-core 4.18.16 300.fc29 x86_64
#>=Prv: installonlypkg(kernel)
#>=Prv: kernel-core-uname-r = 4.18.16-300.fc29.x86_64
#>
#>=Pkg: kernel-core 4.19.15 300.fc29 x86_64
#>=Prv: installonlypkg(kernel)
#>=Prv: kernel-core-uname-r = 4.19.15-300.fc29.x86_64
#>
#>=Pkg: kernel-modules 4.18.16 300.fc29 x86_64
#>=Req: kernel-core-uname-r = 4.18.16-300.fc29.x86_64
#>=Prv: installonlypkg(kernel-module)
#>=Prv: kernel-modules-uname-r = 4.18.16-300.fc29.x86_64
#>
#>=Pkg: kernel-modules 4.19.15 300.fc29 x86_64
#>=Req: kernel-core-uname-r = 4.19.15-300.fc29.x86_64
#>=Prv: installonlypkg(kernel-module)
#>=Prv: kernel-modules-uname-r = 4.19.15-300.fc29.x86_64

repo available 0.0 testtags <inline>
#>=Pkg: kernel-core 4.20.6 300.fc29 x86_64
#>=Prv: installonlypkg(kernel)
#>=Prv: kernel-core-uname-r = 4.20.6-300.fc29.x86_64
#>
#>=Pkg: kernel-core 4.19.15 300.fc29 x86_64
#>=Prv: installonlypkg(kernel)
#>=Prv: kernel-core-uname-r = 4.19.15-300.fc29.x86_64
#>
#>=Pkg: kernel-core 4.18.16 300.fc29 x86_64
#>=Prv: installonlypkg(kernel)
#>=Prv: kernel-core-uname-r = 4.18.16-300.fc29.x86_64

system x86_64 rpm @System
poolflags implicitobsoleteusescolors whatprovideswithdisabled
solverflags allowdowngrade allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job multiversion provides installonlypkg(kernel)
job multiversion provides installonlypkg(kernel-module)

job install oneof kernel-core-4.18.16-300.fc29.x86_64@@System kernel-core-4.19.15-300.fc29.x86_64@@System kernel-core-4.18.16-300.fc29.x86_64@available kernel-core-4.19.15-300.fc29.x86_64@available kernel-core-4.20.6-300.fc29.x86_64@available [forcebest,setevr,setarch]

job install pkg kernel-core-4.20.6-300.fc29.x86_64@available
job install pkg kernel-core-4.19.15-300.fc29.x86_64@@System
job erase pkg kernel-core-4.18.16-300.fc29.x86_64@@System

job allowuninstall pkg kernel-4.18.16-300.fc29.x86_64@@System
job allowuninstall pkg kernel-4.19.15-300.fc29.x86_64@@System
job allowuninstall pkg kernel-core-4.18.16-300.fc29.x86_64@@System
job allowuninstall pkg kernel-core-4.19.15-300.fc29.x86_64@@System
job allowuninstall pkg kernel-modules-4.18.16-300.fc29.x86_64@@System
job allowuninstall pkg kernel-modules-4.19.15-300.fc29.x86_64@@System

result transaction,problems <inline>
#>install kernel-core-4.20.6-300.fc29.x86_64@available
#>reinstall kernel-core-4.18.16-300.fc29.x86_64@@System kernel-core-4.18.16-300.fc29.x86_64@available

I think solver chose this solution over

result transaction,problems <inline>
#>install kernel-core-4.20.6-300.fc29.x86_64@available
#>erase kernel-4.18.16-300.fc29.x86_64@@System
#>erase kernel-core-4.18.16-300.fc29.x86_64@@System
#>erase kernel-modules-4.18.16-300.fc29.x86_64@@System

because it is smaller but we are trying to achieve the latter.

One possible way how to fix this seems to be by adding job lock pkg kernel-core-4.18.16-300.fc29.x86_64@available. Can you please advise us if this is a good solution? Or is there some better way how to do this?

[j-mracek]

Just background of the workflow - dnf receive a transaction and then we check whether transaction adds installonly packages over limit. If it is the case we add additional jobs that erase installonly package over limit and add install steps for installonly package from previously resolved transaction and installed packages that we want to keep on the system.

[mlschroe]

You also get the desired result if you don't include kernel-core-4.18.16-300.fc29.x86_64@available in the install job. But adding the lock like you suggested would also work (I would not use lock, but also add an erase job, but that's a matter of taste)

[kontura]

Thank you for the confirmation and suggestion. I also like the erase more. :+1: