Hello Ryan,

On Thu, May 26, 2022 at 01:28:58PM -0500, Ryan O'Hara wrote:
> I am the maintainer for all the Red Hat and Fedora packages. Feel free to
> ask questions here on the mailing list or email me directly.
> I try to keep Fedora up to date with latest upstream, but once a release
> goes into a specific Fedora release (eg. haproxy-2.4 in Fedora 35) I don't
> update to haproxy-2.5 in that same release. I have in the past and I get
> angry emails about rebasing to a newer release. I've spoken to Willy about
> this in the past and we seem to be in agreement on this.
> RHEL is different. We almost never rebase to a later major release for the
> lifetime of RHEL. The one exception was when we added haproxy-1.8 to RHSCL
> (software collections) in RHEL7 since the base RHEL7 had haproxy-1.5 and
> there were significant features added to the 1.8 release.
> I get this complaint often for haproxy in RHEL. Keep in mind that RHEL is
> focused on consistency and stability over a long period of time. I can't
> stress this enough - it is extremely rare to rebase to a new, major release
> of haproxy (or anything else) in a major RHEL release. For example, RHEL9
> has haproxy-2.4 and will likely always have that version.

I understand your point, indeed RHEL is focused on stability and it
seems normal that the packages maintained inside RHEL does not jump from
one major version to another. 

> I do often rebase to newer minor release to pick up bug fixes (eg.
> haproxy-2.4.8 will be updated to haproxy-2.4.17, but very unlikely to
> be anything beyond the latest 2.4 release). I understand this is not
> for everybody.

That's the right way to do it in my opinion, a stable distribution
just needs to follow the minor releases which basically contains the

But what we are trying to offer is a way for users to chose another
branch so they could benefits from new features. Since RHEL has a long
life cycle and HAProxy has 2 majors releases per year, RHEL can't
provide them and that's normal.

Some users actually need up to date versions because the needs evolve,
the tools, and the protocols too. For example someone who want to use
the latest dynamic features with their kubernetes, or who wants to test

Debian had the same problem as RHEL, but it was solved with
haproxy.debian.net which provides multiple HAProxy branches for multiple
debian versions. It would be great if we can achieve something like this
with COPR or anything else.

> As mentioned elsewhere, COPR is likely the best place for this. It had been
> awhile since I've used it, but there have been times I did special,
> unsupported builds in COPR for others to use.
> Hope this helps.
> Ryan


William Lallemand

Reply via email to