osbuild-depsolve-dnf: refactor into osbuild.solver module #1776
Conversation
|
🔥 |
bcl
force-pushed
the
main-solver
branch
2 times, most recently
from
532284f
to
54d69c3
Compare
bcl
changed the title
|
FTR, we are currently relying on the fact that I really love this PR, but we need to make sure that we have a way forward in the b-i-b world before merging this. :) |
I'm still not entirely sure why we need to copy the script into the base OS container (buildroot) to run it in BIB. What happens when we call it from the outside and point it to the buildroot for the repo configs? |
IMO this is a bib bug, it should be installing osbuild in the container and using it properly. |
It's already in the BIB container. It gets copied into the target image container (the user's extracted container) and run within that container's root. Because we're container native I guess. |
With the new "dnf5" solver is seems useful to allow the dnfjson code return what solver was actually used in the transaction. This commit allows an (optional) "solver" field in the json that is returned from the dnfjson helper. It does not do more yet but we should (probably) make it avaialble for the higher layers too so that it can be e.g. logged. See also osbuild/osbuild#1776
With the new "dnf5" solver is seems useful to allow the dnfjson code return what solver was actually used in the transaction. This commit allows an (optional) "solver" field in the json that is returned from the dnfjson helper. It does not do more yet but we should (probably) make it avaialble for the higher layers too so that it can be e.g. logged. See also osbuild/osbuild#1776
With the new "dnf5" solver is seems useful to allow the dnfjson code return what solver was actually used in the transaction. This commit allows an (optional) "solver" field in the json that is returned from the dnfjson helper. It does not do more yet but we should (probably) make it avaialble for the higher layers too so that it can be e.g. logged. See also osbuild/osbuild#1776
This moves the dnf and dnf5 code into a new osbuild module called solver. The dnf specific code is in dnf.py and dnf5 is in dnf5.py At runtime the osbuild-depsolve-dnf script reads a config file from /usr/lib/osbuild/solver.json and imports the selected solver. This currently just contains a 'use_dnf5' bool but can be extended to support other configuration options or depsolvers. At build time a config file is selected from tools/solver-dnf.json or tools/solver-dnf5.json and installed. Currently dnf5 is not installed, it will be added when dnf5 5.2.1.0 becomes available in rawhide (Fedora 41). The error messages have been normalized since the top level functions in osbuild-depsolve-dnf do not know which version of dnf is being used.
Test with no config file (libdnf), with use_dnf5 set to false, and with it set to true. Make sure the correct dnf library was used.
I don't think we ever have, the depsolve-dnf subpackage requires osbuild with a matching version. |
This moves the dnf and dnf5 code into a new osbuild module called
solver. The dnf specific code is in dnf.py and dnf5 is in dnf5.py
At runtime the osbuild-depsolve-dnf script reads a config file from
/usr/lib/osbuild/solver.json and imports the selected solver. This
currently just contains a 'use_dnf5' bool but can be extended to support
other configuration options or depsolvers.
At build time a config file is selected from tools/solver-dnf.json or
tools/solver-dnf5.json and installed. Currently dnf5 is not installed,
it will be added when dnf5 5.2.1.0 becomes available in rawhide (Fedora
41).
The error messages have been normalized since the top level functions in
osbuild-depsolve-dnf do not know which version of dnf is being used.