|Summary:||net/haproxy include Lua support by default|
|Product:||Ports & Packages||Reporter:||Mark Deneen <mdeneen>|
|Component:||Individual Port(s)||Assignee:||Dmitry Sivachenko <demon>|
|Severity:||Affects Some People||CC:||dch, mdeneen|
Description Mark Deneen 2021-04-14 13:33:57 UTC
Created attachment 224106 [details] patch for ports tree to change defaults Lua has been available for many years now in haproxy, and is included by default in packages available for Debian, Ubuntu, and Redhat. It is also required to use haproxy's Let's Encrypt ACMEv2 client, something which allows users to automate renewing TLS certificates and reloading them with zero down time. With this in mind, I feel that the default in FreeBSD should be kept in line with the defaults set elsewhere in order to have a more pleasant experience if they are testing migrating services from Linux to FreeBSD. I have included a patch to change the defaults.
Comment 1 Dmitry Sivachenko 2021-04-18 12:47:03 UTC
Well, I don’t feel we should follow Linux. Haproxy provides a feature-rich load balancer without Lua. Some things require Lua. I would keep it without extra dependency by default, I think the majority of installations do not neec Lua dependency.
Comment 2 Mark Deneen 2021-04-19 13:54:21 UTC
(In reply to Dmitry Sivachenko from comment #1) Dmitry, I understand that following Linux is not a goal. It is, however, a requirement if you wish to use CORS (https://www.haproxy.com/blog/enabling-cors-in-haproxy/) or ACMEv2. These are all possible out-of-the box in Linux. I get it, we're not following Linux, but I do feel that this will put FreeBSD at a disadvantage as more and more of these "side projects" of haproxy are implemented in Lua. Why you think that the majority of users do not require the Lua dependency? How would one know this? Mark
Comment 3 Dave Cottlehuber 2021-04-19 13:59:35 UTC
I'm down to just 3 packages that *require* us to run our own poudriere setup these days, haproxy is one of them. It's not difficult to do so, naturally, but its yet another reason for newcomers to FreeBSD to fall by the wayside. Is this something we can add as an option, or a subsidiary port (aka nginx variants)? Would adding this cause an undue burden on the maintainer? Theres almost as many people asking for it now as ftp in base ;-) I'm happy to provide a patch either way.
Comment 4 Dmitry Sivachenko 2021-04-20 12:24:48 UTC
(In reply to Mark Deneen from comment #2) Following that logic we should build every port with all available OPTIONs set on by default, because someone need them.
Comment 5 Dmitry Sivachenko 2021-04-20 12:26:14 UTC
(In reply to Dave Cottlehuber from comment #3) I think that we may consider using FLAVORs to have two versions of a port: default without lua and "-lua" flavor with lua.
Comment 6 Mark Deneen 2021-04-20 13:27:10 UTC
(In reply to Dmitry Sivachenko from comment #4) I am only suggesting that options required to use haproxy's official ACMEv2 client, something which many people use, should be enabled. I am not, at all, advocating that all options be enabled in all ports. The difference here is that the ACMEv2 and CORS functionality are developed and published by the haproxy project.
Comment 7 Dave Cottlehuber 2021-04-20 15:45:38 UTC
(In reply to Dmitry Sivachenko from comment #5) that sounds perfect. I've got a full week already, but I'm keen to have a look next week.
Comment 8 Mark Deneen 2021-04-20 21:04:04 UTC
Created attachment 224313 [details] add Lua flavor to haproxy ports I took a stab at adding a flavor to the haproxy ports. I'm not well versed in the FreeBSD world, but I think that I've followed the FLAVOR examples found in other ports fairly well. The one place I was unsure was in the CONFLICTS_INSTALL line. I attempted to test this by installing haproxy23-lua and then installing haproxy23. It told me that there was a conflict, but it was because both packages provided /usr/local/man/man1/haproxy.1.gz and not because of the package name match. Maybe this is the expected behavior, or maybe because I've done something wrong. My match might be too greedy -- you tell me. With that being said, I attempted to handle both flavors in the CONFLICTS_INSTALL definition. There were a few ports which were missing matches for newer haproxy releases. For example, haproxy21 would not conflict with haproxy23. I have corrected these, although I don't think that this line is explicitly required since it seems to grumble about packages containing the same file path first. If this isn't the way to do things, please let me know. At best, I may have helped move this forward and saved you some time and at worst I will have learned something. All the best, Mark Deneen
Comment 9 Mark Deneen 2021-04-21 14:48:08 UTC
Created attachment 224331 [details] previous patch had a mistake in haproxy18, this corrects that oversight. There was a missing line in my previous patch for haproxy18. This corrects that issue and should be applied after the previous patch. If required, I can roll them into one updated patch.
Comment 10 commit-hook 2021-05-05 17:03:53 UTC
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=41f30e3a1f9c00af87bbb9124fe89b35d6fb89f4 commit 41f30e3a1f9c00af87bbb9124fe89b35d6fb89f4 Author: Dmitry Sivachenko <demon@FreeBSD.org> AuthorDate: 2021-05-05 17:01:23 +0000 Commit: Dmitry Sivachenko <demon@FreeBSD.org> CommitDate: 2021-05-05 17:03:25 +0000 net/haproxy: add lua flavor. PR: 255052 Submitted by: Mark Deneen <firstname.lastname@example.org> net/haproxy/Makefile | 11 +++++++++++ 1 file changed, 11 insertions(+)
Comment 11 Dmitry Sivachenko 2021-05-05 17:06:02 UTC
I committed you patch for net/haproxy. Thanks! We'll see how it goes. I am still not sure we should propagate these changes for all other haproxy versions, since net/haproxy is the main production branch and others are provided only for historical reasons. Double the number of packages could be overkill.