Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change dnf-yum to yum in Fedora package sets #637

Merged
merged 1 commit into from
Apr 26, 2024

Conversation

AdamWill
Copy link
Contributor

@AdamWill AdamWill commented Apr 25, 2024

In Fedora, there is no 'dnf-yum' package. dnf-yum is provided by yum (which is a subpackage of dnf, confused yet?)

With the dnf5-replacing-dnf transition, dnf5 includes the file /usr/bin/yum and provides and obsoletes 'yum', but it does not provide 'dnf-yum'. In a test of a Kiwi image build using a config which specified 'dnf-yum', this caused a failure, because dnf wanted to pull in 'yum' to satisfy the 'dnf-yum' specification, but it was obsoleted by dnf5 (which it was pulling in as the provider of 'dnf'), so it gave up. I suspect we'd have the same problem with osbuild builds that specify 'dnf-yum'. I think changing it to just 'yum' will solve the problem while remaining compatible across Fedora releases before and after the dnf5 switchover, because in earlier releases, this will pull in the 'yum' package as before, and in later releases, dnf should decide that the 'dnf5' package provides both it and 'dnf', and be happy installing that.

In Fedora, there is no 'dnf-yum' package. dnf-yum is provided
by yum (which is a subpackage of dnf, confused yet?)

With the dnf5-replacing-dnf transition, dnf5 includes the file
/usr/bin/yum and provides and obsoletes 'yum', but it does not
provide 'dnf-yum'. In a test of a Kiwi image build using a config
which specified 'dnf-yum', this caused a failure, because dnf
wanted to pull in 'yum' to satisfy the 'dnf-yum' specification,
but it was obsoleted by dnf5 (which it was pulling in as the
provider of 'dnf'), so it gave up. I suspect we'd have the same
problem with osbuild builds that specify 'dnf-yum'. I think
changing it to just 'yum' will solve the problem while remaining
compatible across Fedora releases before and after the dnf5
switchover, because in earlier releases, this will pull in the
'yum' package as before, and in later releases, dnf should decide
that the 'dnf5' package provides both it and 'dnf', and be happy
installing that.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
@achilleas-k
Copy link
Member

Sounds complicated 😆
Thanks for looking into the whole thing and explaining it.

So this shouldn't change anything in the images and I just checked now and it does seem that test manifests are identical and the CI runs should confirm it.

Copy link
Member

@achilleas-k achilleas-k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@AdamWill
Copy link
Contributor Author

right, for the pre-transition case it should result in the exact same build (because we're already using the package called 'yum' to satisfy the spec 'dnf-yum'). post-transition, specifying 'dnf-yum' will likely cause a conflict (as it did with kiwi), while the specification 'yum' will be satisfied by the package called 'dnf5' (which is indeed the thing meant to provide /usr/bin/yum in a dnf5-as-default world).

@achilleas-k achilleas-k added this pull request to the merge queue Apr 26, 2024
@AdamWill
Copy link
Contributor Author

huh. what's the deal with the failed f40 unit tests? I can't really see what's going on there.

Merged via the queue into osbuild:main with commit 48eb7c2 Apr 26, 2024
16 of 17 checks passed
@achilleas-k
Copy link
Member

huh. what's the deal with the failed f40 unit tests? I can't really see what's going on there.

Sorry, missed this comment.

It's not an issue. We had some unit tests that were failing on Fedora 40 because of the depsolver changing to use dnf5 (for F40 only) and error messages weren't matching expected ones in tests. The F40 tests were not required at the time because of this, but it's been fixed now (since yesterday).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants