DNF options during blueprint depsolve/install ?
Opened this issue · 7 comments
It is unclear how to pass arguments to DNF during the compose process or if that is even possible currently.
org.osbuild.dnf.config mentions
Allows defining dnf variables via the `variables` option and
specific configuration options via the `config` option. The
latter will be saved in `/etc/dnf/dnf.conf`. See `dnf.conf(5)`
for details about the configuration options.
It is unclear where the variables option should be provided and further guidance would be excellent.
Can you be more specific about your needs? Do you need to change the config of dnf when the image isn't being depsolved and built, or when the image is booted?
Sure.
I'd like to specify flags for DNF during the depsolve/build process.
I have a package that conflicts with another from a group install.
I was hoping to provide --allowerasing or --setopt=install_weak_deps=False to DNF within the bwrap environment.
Currently I get an error due to the conflicting package.
I suppose those are two separate phases though ..
If the blueprint fails depsolve (due to the conflict) the pipeline would never really start.
So is it possible to have a conflict in the blueprint if DNF is expected to erase the conflicting package later on or not at all?
So basically you want to replace a package from the set that osbuild-composer defines with a different one? We are actually discussing this pretty often nowadays. Are you able to share a concrete example? We are collecting usecases when users need to replace a package from the base set.
cc @supakeen
I have to omit some of the details but I can share the interesting parts of my case.
In blueprint.toml I have
name = "Some-Name"
description = "Some-Text"
version = "1.0.0"
modules = []
groups = []
[[packages]]
name = "@Core"
version = "*"
[[packages]]
name = "@Server With GUI"
version = "*"
[[packages]]
name = "our-metapackage"
version = "0.0.1"
Now our-metapackage states Conflicts: gnome-initial-setup along with some Requires: and Recommends: because we don't care for the users of our image to have the OOB Gnome experience, but we do care to include certain things that we have packaged to deliver various configurations.
This Conflicts: statement is what was failing depsolve.
I have adjusted my current process to install some of the recommends in the blueprint rather than the full package because I could not determine if it was possible to defer installation of weak dependencies / resolve conflicts in the depsolve phase.
Some of our weak deps do not want to be present in the image anyway because they create unique artifacts so it is preferable to defer those to when the system actually boots.
@ondrejbudai it seems to me that @sjr0228 wants to allow erasing in the depsolve for the customizations (blueprint). This is likely something that we could expose in blueprints together with allowing the specification of weak dependency installation as merged in osbuild/images#39 though it will allow users to define things that can't be depsolved, same as allowing excludes in blueprints.
@sjr0228 in this case the conflicting package is pulled in by a weak-dep of something in one of the comps groups?
Small side-question; which distro are you building?
rpm -q --whatrequires and rpm -q --whatsuggests report no inverse strong or weak relationship between gnome-initial-setup and anything else.
The only relationship I have found is that gnome-initial-setup is a mandatory member of the @GNOME group which is a mandatory member of @Server With GUI.
I am building EL8.8.