On 2022-05-26 20:28, Ryan O'Hara wrote:
On Wed, May 25, 2022 at 11:15 AM William Lallemand
<wlallem...@haproxy.com> wrote:

On Tue, May 24, 2022 at 08:56:14PM +0000, Alford, Mark wrote:
Do you have instruction on the exact library needed to fo the full
install on RHEL 7 and RHEL 8

I read the INSTALL doc in the tar ball and the did the make
command and it failed because of LUA but lua.2.5.3 is installed

Please help


I'm using this thread to launch a call for help about the redhat

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.

We try to document the list of available packages here:

The IUS repository is know to work but only provides packages as far
2.2. no 2.3, 2.4 or 2.5 are there but I'm seeing an open ticket for
the 2.4 here: https://github.com/iusrepo/wishlist/issues/303

Unfortunately nobody ever step up to maintain constantly the
releases for redhat/centos like its done for ubuntu/debian on
haproxy.debian.net [1].

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

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

IMHO, if you pick a LTS or even a non-LTS (depending on how long the distro version ist being supported) but keep that
close to upstream releases by doing minor bumps, that's totally fine.
That way, like you said, users get bug fixes and not just hand picked patches. That's far better I'd say.

Maybe it could be done with IUS, its as simple as a pull request on
their github for each new release, but someone need to be involve.

I'm not a redhat user, but from time to time someone is asking for a
redhat package and nothing is really available and maintained
outside of
the official redhat one.

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.


[1] http://haproxy.debian.net

Christian Ruppert

Reply via email to