> 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.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2748#issuecomment-1801714244
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2748/c1801714...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to