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

Adapt Dockerfile.fedora to F39 #2748

Merged
merged 1 commit into from
Nov 9, 2023

Conversation

dmnks
Copy link
Contributor

@dmnks dmnks commented Nov 7, 2023

The fedora-repos-modular package is gone from F39. This commit makes the Dockerfile work on a F39 host with the mktree.oci backend since we override the release with "podman build --from fedora:39 ..." there.

The fedora-repos-modular package is gone from F39.  This commit makes
the Dockerfile work on a F39 host with the mktree.oci backend since we
override the release with "podman build --from fedora:39 ..." there.
@dmnks dmnks force-pushed the fix-dockerfile-f39 branch from 732d057 to 53f4c37 Compare November 7, 2023 15:49
Copy link
Member

@pmatilai pmatilai left a comment

Choose a reason for hiding this comment

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

If you say so, but I find the notion of the host affecting something inside the Dockerfile (or vice versa) more than just a little mind-bending 😳

On a related note, possible alternatives include just bumping the CI to F39 now that it's out, or disabling the repos with sed like we do for the h264 repo.

@dmnks
Copy link
Contributor Author

dmnks commented Nov 8, 2023

If you say so, but I find the notion of the host affecting something inside the Dockerfile (or vice versa) more than just a little mind-bending 😳

I do find it ugly and hacky, too, don't get me wrong. It violates the very principle of a Dockerfile being immutable. It's only done so that the image is ensured to contain the ABI compatible dependencies of RPM with those that it was built against locally.

This makes me think, do we really need to test the local, native build? I've been operating with that assumption from the start but maybe it's just backwards... We might as well just always do the build in the Dockerfile and test that, like in CI. This would simplify the whole setup a bit more, too.

On a related note, possible alternatives include just bumping the CI to F39 now that it's out

This would just move the "problem" to F38 hosts where we'd call podman build --from fedora:38 with this Dockerfile...

or disabling the repos with sed like we do for the h264 repo.

Yeah, this sounds like a cleaner way, indeed.

@pmatilai pmatilai merged commit f851bce into rpm-software-management:master Nov 9, 2023
1 check passed
@pmatilai
Copy link
Member

pmatilai commented Nov 9, 2023

The local build probably needs to go eventually, but lets leave this alone for now. We need to move to other challenges...

@dmnks dmnks added the test Testsuite-related label Nov 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Testsuite-related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants