https://bugzilla.redhat.com/show_bug.cgi?id=1885415
Robert Scheck <redhat-bugzilla(a)linuxnetz.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?(carl(a)redhat.com)
--- Comment #3 from Robert Scheck <redhat-bugzilla(a)linuxnetz.de> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component