Bug 1885415

Created attachment 1719178 [details]
Diff between current HAProxy from RHEL 8 and this package

As we were discussing on IRC, this package doesn't need a formal review.  It falls under bullet point two here [0] of multiple versions of the same package.

That said, there are a few things that need to be corrected.

1. The package should to be named haproxy1.8 to comply with the naming guidelines [1].  Please close the current fedscm repo request [2] and re-do it as haproxy1.8 (still with the `--exception` flag).

2. The /var/lib/haproxy directory already exists in the RHEL haproxy package.  Sharing the state directory could disturb the base package, which is not allowed by EPEL policy [3].

3. I understand what you're trying to do with the syspaths subpackage, but similar to the previous item, this is not allowed by policy, as the files would conflict with the RHEL haproxy package.


[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
[2] https://pagure.io/releng/fedora-scm-requests/issue/29940
[3] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy

(In reply to Carl George 🤠 from comment #2)
> 1. The package should to be named haproxy1.8 to comply with the naming
> guidelines [1].  Please close the current fedscm repo request [2] and re-do
> it as haproxy1.8 (still with the `--exception` flag).

Did I overlook something? It says "All other packages derived from it MUST include the base name suffixed by either: [bullet point] The package version, which SHOULD include the periods present in the original version. [...]" - not MUST, thus "haproxy18" should be sufficient.

> 2. The /var/lib/haproxy directory already exists in the RHEL haproxy
> package.  Sharing the state directory could disturb the base package, which
> is not allowed by EPEL policy [3].

I have explicitly ensured in the default configuration of haproxy18, that there is no file conflict or overlap within the state directory at al. Further on, I even actually tested whether both packages can coexist during run-time without disturbing each other. Note that the official SCL rh-haproxy18-haproxy-1.8.24-2.el7 does exactly the same here (because they all share the haproxy user/group and its home directory, while changing the home directory of the haproxy user actually would disturb the base package).

> 3. I understand what you're trying to do with the syspaths subpackage, but
> similar to the previous item, this is not allowed by policy, as the files
> would conflict with the RHEL haproxy package.

Even this is a completely optional subpackage, the admin needs to explicitly install? If that remains the only blocker, I will drop the subpackage then.

> Did I overlook something? It says "All other packages derived from it MUST include the base name suffixed by either: [bullet point] The package version, which SHOULD include the periods present in the original version. [...]" - not MUST, thus "haproxy18" should be sufficient.

What is the justification for not following the guideline?  Most packages that do not follow this were created before the guideline existed.  New packages going forward need to follow it unless there is a good reason not to.  On a related note, once the package name is changed to haproxy1.8, the path suffixes should probably be 1.8 instead of 18 as well for consistency.

> I have explicitly ensured in the default configuration of haproxy18, that there is no file conflict or overlap within the state directory at al. Further on, I even actually tested whether both packages can coexist during run-time without disturbing each other. Note that the official SCL rh-haproxy18-haproxy-1.8.24-2.el7 does exactly the same here (because they all share the haproxy user/group and its home directory, while changing the home directory of the haproxy user actually would disturb the base package).

rh-haproxy18-haproxy uses /var/opt/rh/rh-haproxy18/lib/haproxy.  It also owns the /var/lib/haproxy directory as the home directory of the shared haproxy user, but it explicitly doesn't use it.  If you want to follow the SCL package's example, you need to use a different state directory as well.  If the /var/lib/haproxy directory in your package is empty and unused, then it would meet EPEL guidelines in my opinion.  Just using a different path for the stats socket is not sufficient, because that assumes that haproxy will never write anything else to that directory.  That may be true, but we should play it safe and not make assumptions.

> Even this is a completely optional subpackage, the admin needs to explicitly install? If that remains the only blocker, I will drop the subpackage then.

Every package in EPEL is optional, and EPEL packages are not allowed to have file conflicts with RHEL packages.


P.S. There is no need to use the needinfo flag, I'm cc'ed on the bug already.  All you accomplished by that is sending me two email notifications instead of one.  You should also be aware that until the flag is cleared, bugzilla will continue to email me every few days.  We all get too much email as it is, so please respect people's inboxes and only use the needinfo flag sparingly, such as when someone is non-responsive for several weeks.

(In reply to Carl George 🤠 from comment #4)
> What is the justification for not following the guideline?  Most packages
> that do not follow this were created before the guideline existed.  New
> packages going forward need to follow it unless there is a good reason not
> to.  On a related note, once the package name is changed to haproxy1.8, the
> path suffixes should probably be 1.8 instead of 18 as well for consistency.

I would like to see the haproxy18 package as a strong and direct competitor to Red Hat's rh-haproxy18 package, not only due to the main feature difference (TLSv1.3), but also by its quite similar package name. And especially for RHEL 7, administrators are used to versioned packages without a dot, be it python36, mozjs17, mozjs24, mozjs52, rh-gitXX, rh-mariadbXXX, rh-perlXXX, rh-phpXX or rh-postgresqlXX to just name a few quite common ones. Being also an administrator myself, I find it kind of confusing to mix different naming schemes that late on RHEL 7, also once it comes to file and directory path names (note that we are not talking here about e.g. yet another Python library that is automagically added as dependency during installation where the file and directory path names do not really matter, because it's hidden by the programming language, but about a software where administrators, also hopefully migrating from rh-haproxy18, actually need to type these path names or to migrate configurations). This package is not targetting RHEL 8 or similar, where I would agree about a new naming scheme, but the older RHEL 7, where I would like to keep and continue exactly the naming and spirit for the last < 4 years until EOL, that de-facto existed in the > 6 years before. I understand that you might not treat this as a strong justification, but for me as a packager, it's the actual freedom that I see by "should" rather "must" in the guidelines.

> rh-haproxy18-haproxy uses /var/opt/rh/rh-haproxy18/lib/haproxy.  It also
> owns the /var/lib/haproxy directory as the home directory of the shared
> haproxy user, but it explicitly doesn't use it.  If you want to follow the
> SCL package's example, you need to use a different state directory as well. 
> If the /var/lib/haproxy directory in your package is empty and unused, then
> it would meet EPEL guidelines in my opinion.  Just using a different path
> for the stats socket is not sufficient, because that assumes that haproxy
> will never write anything else to that directory.  That may be true, but we
> should play it safe and not make assumptions.

Playing safe is indeed a valid argument (even I did various checks), so I've changed the path.


Spec URL: http://labs.linuxnetz.de/bugzilla/haproxy18.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/haproxy18-1.8.23-2.el7.src.rpm

Created attachment 1724010 [details]
Diff between current HAProxy from RHEL 8 and this package

Robert, please change the version suffix to the accurate version string. In general, we are trying to stop having packages named with versions lacking the separators because it's confusing to most people and causes other issues for third parties. That's why Python has finally stopped doing this, and LLVM stopped doing this a long time ago.

Neal, I explained above why I would like to use the freedom from 'should', and I've doubts that the old EPEL 7 branch is the right candidate to enforce a (currently) non-mandatory guideline that strongly like it happens in this RHBZ. I agree for more recent branches like EPEL 8, but not for EPEL 7.

> This package is not targetting RHEL 8 or similar, where I would agree about a new naming scheme, but the older RHEL 7, where I would like to keep and continue exactly the naming and spirit for the last < 4 years until EOL, that de-facto existed in the > 6 years before.

This is a really good point.  You've convinced me.  Feel free to proceed with importing to the haproxy18 repo that has already been requested.

> Diff between current HAProxy from RHEL 8 and this package

One small suggested tweak, rather than mucking with the regparm_opts variable, just delete USE_LUA=1 from the make command a few lines later.

FEDORA-EPEL-2020-0d6230d04e has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d6230d04e

FEDORA-EPEL-2020-0d6230d04e has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d6230d04e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2020-0d6230d04e has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.