https://bugzilla.redhat.com/show_bug.cgi?id=1885415 Carl George 🤠 <carl@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(carl@xxxxxxxxxx) | --- Comment #4 from Carl George 🤠 <carl@xxxxxxxxxx> --- > 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. -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
