Skip to content

ENT-13867: Added RHEL 8,9,10 support to build in container#2338

Open
aleksandrychev wants to merge 1 commit into
cfengine:masterfrom
aleksandrychev:ENT-13867
Open

ENT-13867: Added RHEL 8,9,10 support to build in container#2338
aleksandrychev wants to merge 1 commit into
cfengine:masterfrom
aleksandrychev:ENT-13867

Conversation

@aleksandrychev

Copy link
Copy Markdown
Contributor

Ticket: ENT-13867

Ticket: ENT-13867
Signed-off-by: Ihor Aleksandrychiev <ihor.aleksandrychiev@northern.tech>
Comment thread container/Dockerfile.rhel
@@ -0,0 +1,64 @@
ARG BASE_IMAGE=rockylinux/rockylinux:9
FROM ${BASE_IMAGE}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't think we should duplicate in a different way what we do in the build host setup. I would be fine with choosing either policy or scripts but not both.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@craigcomstock I took https://github.com/cfengine/buildscripts/blob/master/container/Dockerfile.debian as reference, you mean install cfengine to install dependencies? If yes I'd like to have scripts rather than policies in this case to avoid chicken\egg problem when new platforms added.

@craigcomstock craigcomstock Jul 13, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Using policy hasn't bought us so much and caused some trouble.

I would suggest we begin refactoring to stop using that policy and instead use scripts.

The goal was to make it "easier" to manage and this has not been the result.

Feel free to make a follow-up ticket for migrating away from policy to scripts for build host setup.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@craigcomstock I took https://github.com/cfengine/buildscripts/blob/master/container/Dockerfile.debian as reference, you mean install cfengine to install dependencies? If yes I'd like to have scripts rather than policies in this case to avoid chicken\egg problem when new platforms added.

Also, there is a provision to build from source enough to bootstrap a new platform. If that doesn't work then we should fix it or remove it. It did work recently for rhel-10-arm fwiw. https://github.com/cfengine/buildscripts/blob/master/ci/setup-cfengine-build-host.sh#L217

Comment thread container/Dockerfile.rhel
@@ -0,0 +1,64 @@
ARG BASE_IMAGE=rockylinux/rockylinux:9

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ideally we will use these to build our packages so it seems we should use ubi/rhel images and not rocky.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I looked into UBI, but its repos only contain a free redistributable subset of RHEL, and some packages we need to build (bison, flex, pam-devel, selinux-policy-devel) aren't included, see the public repo listing, e.g. no bison in the appstream: https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi9/9/x86_64/appstream/os/Packages/b/ . Getting them on UBI requires RHEL entitlement certs inside the image build.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That is correct. @olehermanse @nickanderson @vpodzime how would you suggest we proceed? Is the difference between rockylinux and rhel so little that we can rely on rockylinux to build?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

So many redhat issues. Most of our users are rhel proper. for basic building irocky might be ok but we need regular tests against rhel for real i think

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@craigcomstock short answer; I don't know. Long answer; we're splitting up building and testing, in theory, as long as we test on RHEL proper, I think it should be okay to build on something "similar enough".

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is the difference between rockylinux and rhel so little that we can rely on rockylinux to build?

Why not CentOS Stream?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Is the difference between rockylinux and rhel so little that we can rely on rockylinux to build?

Why not CentOS Stream?

CentOS Stream sits ahead of RHEL. It's a rolling preview of the next RHEL minor release, so it can include newer versions of dependencies that haven't been released in RHEL yet. Rocky is a downstream (100% bug-for-bug compatible with Red Hat Enterprise Linux, as they claim).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Right, so RHEL sits between Rocky and CentOS Stream. I think both of those options are equally good or bad.

- debian-11
- debian-12
- debian-13
- rhel-8

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We might need Red Hat 7 as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

6 participants