chore(rpm-ostree): Include option for enabling/disabling `cliwrap`

[fiftydinar]

Reason for enabling this is to avoid confusion & improve the experience of the users who would install custom kernels.

Cliwrap documentation: https://coreos.github.io/rpm-ostree/cliwrap/

While cliwrap mostly contains function of redirecting legacy programs like dnf to behave like rpm-ostree, the actual useful change is that dracut is wrapped to be compatible with Fedora Atomic initramfs.

dracut is used by custom kernels to modify initramfs, so they can install successfully. Without cliwrap installed, many kernels fail to install on Fedora Atomic.

This is how installing cliwrap can be done:

if [[ ! -f "/usr/libexec/rpm-ostree/wrapped/dracut" ]]; then
  echo "Installing cliwrap"
  rpm-ostree cliwrap install-to-root /
else
  echo "Cliwrap is already installed"
fi

We can enable this by default, while making it available to disable in options.

[gmpinder]

Should this be something that's done in the CLI? Seems like something we'd want to enable by default

[xynydev]

Doing it in the CLI would be yet another rpm-ostree-specific thing that it does, and if someone wanted to opt out of cliwrap for any reason there wouldnt be an effective way to allow such a configuration. It is very likely that an user that would benefit from this is using the rpm-ostree module.

[gmpinder]

Doing it in the CLI would be yet another rpm-ostree-specific thing that it does, and if someone wanted to opt out of cliwrap for any reason there wouldnt be an effective way to allow such a configuration. It is very likely that an user that would benefit from this is using the rpm-ostree module.

But if a user tries to use dracut, for example, before making a call to the rpm-ostree module it won't be wrapped. Which is why I suggest putting it in the CLI so that we can call it immediately. If allowing the user to disable that is something we want, we can add a property in the recipe or use a CLI arg.

[fiftydinar]

But if a user tries to use dracut, for example, before making a call to the rpm-ostree module it won't be wrapped.

Good point.

Which is why I suggest putting it in the CLI so that we can call it immediately.

Sounds good.

If allowing the user to disable that is something we want, we can add a property in the recipe or use a CLI arg.

Config would look cleaner if it belonged in rpm-ostree module though.

Hmm, which implementation method to choose

[gmpinder]

What if we instead added a new property for the rpm-ostree module called cli-wrap. It would take a Boolean and if true we'd enable the CLI wrap. This way it's still an explicit action taken by the user and remains in the module.

[xynydev]

That is exactly what I am suggesting. I am not, however, suggesting that CLI would analyze the module list and execute the instruction there in a different order than it is specified.

Having the user run the rpm-ostree module to do cliwrap before doing something that depends on it is not a bug, it is an intentional consequence of the module system.

[fiftydinar]

It seems that behavior of dnf changed in the latest update when cliwrap is enabled.

Rather than warning the user about how rpm-ostree should be used rather than dnf & continuing the process successfully as usual, it now errors out & fails the build.

Some kernels might rely on usage of dnf to install the kernel along with dracut, so in that case, kernels would also fail to install.

But I think this needs to be tested against the current available custom kernels, to see if they're affected or not with this change.

I know that Universal Blue folks have this exact issue with akmods, so they plan to switch the Container to be in classic Fedora format rather than Fedora Atomic.