dracut

dracut copied to clipboard

tpm2-tools dependency can be can be pulled in case tmp2-tss package is installed, using a soft conditional dependency.

https://bugzilla.redhat.com/show_bug.cgi?id=2077697

It is unclear though, how the bug reporter deduced he needs tpm2-tools from the following message:

"dracut: module "crypt" depends on "tpm2-tss", which can't be installed."

Relevant code: https://github.com/dracutdevs/dracut/blob/master/modules.d/90crypt/module-setup.sh#L31

@pvalena the dependency failure is because the tpm2-tss module could not be installed and the reason why tpm2-tss module could not be installed is because the required binary ( tpm2 ) for the module is missing.

The proper packaging fix here is to split dracut modules into their own sub-package which in turn has dependency on what the modules themselves require.

At somepoint in time I will either move the shipped dracut spec into that direction or drop the spec file since upstreams should not be in the role of downstream package maintenance and last time I checked none of the downstream distribution ( Fedora/RHEL/Suse ) was actually using the dracut spec as it's being shipped here upstream.

@pvalena the dependency failure is because the tpm2-tss module could not be installed and the reason why tpm2-tss module could not be installed is because the required binary ( tpm2 ) for the module is missing.

Right, and tpm2-tools contains the binary (that was what I was missing). I'm also asking the maintainer (in Fedora) whether this isn't wrong on their side.

The proper packaging fix here is to split dracut modules into their own sub-package which in turn has dependency on what the modules themselves require.

But recommends results in the same end-state, correct? I see how packaging into subpackages helps to bring dependencies transparently... but also brings another level of complexity, and might complicate any deployments needlesslly. @lnykryn WDYT?

At somepoint in time I will either move the shipped dracut spec into that direction or drop the spec file since upstreams should not be in the role of downstream package maintenance and last time I checked none of the downstream distribution ( Fedora/RHEL/Suse ) was actually using the dracut spec as it's being shipped here upstream.

Right, I agree upstream is not responsible for it, but on the other hand it's a nice way of tracking the dependencies / changes. I can take the responsibility for it, as I do intend to work on upstreaming all changes we do downstream; so it gets properly tested in the CI (and I'm also using the spec file for both RHEL and Fedora).

When I get it fully in sync, the next step is to have the automation (I have created) do the dracut upgrades in Fedora, as I have semi-automated both Fedora and RHEL PRs (with upgrades/fixes) at this point.

But recommends results in the same end-state, correct? I see how packaging into subpackages helps to bring dependencies transparently... but also brings another level of complexity, and might complicate any deployments needlesslly. @lnykryn WDYT?

How complex or broken downstream dependency chain is for the package management solution downstream is using ( and it's dependency chain is severely broken in Fedora/RHEL ) is none of upstream concerns since upstream should not be partaking in downstream package management and the distribution politics surrounding it et all for obvious reasons.

At somepoint in time I will either move the shipped dracut spec into that direction or drop the spec file since upstreams should not be in the role of downstream package maintenance and last time I checked none of the downstream distribution ( Fedora/RHEL/Suse ) was actually using the dracut spec as it's being shipped here upstream.

Right, I agree upstream is not responsible for it, but on the other hand it's a nice way of tracking the dependencies / changes.

For the downstream package maintainer yes but it's also a nice way to exclude contributions to projects as turned out to be the case for us. We will not repeat that mistake no matter how convenient it will be for downstream maintenance/maintainers for any distribution Fedora/RHEL or otherwise.

I can take the responsibility for it, as I do intend to work on upstreaming all changes we do downstream; so it gets properly tested in the CI (and I'm also using the spec file for both RHEL and Fedora).

When I get it fully in sync, the next step is to have the automation (I have created) do the dracut upgrades in Fedora, as I have semi-automated both Fedora and RHEL PRs (with upgrades/fixes) at this point.

I will merge this however I would not be putting to much effort into any future efforts since the dracut spec file is either going away ( along with any other package management system file ) or the package management system related files will not be directly related to distributions but instead be related to the package management solution themselves and only exist as a guide from upstream how they should be package in downstream distribution with correct dependency chain. If that happens to align with some distribution(s) using particular package management system file great! if not well the downstream maintainers are on their own carrying their own for their distribution downstream.