https://bugzilla.redhat.com/show_bug.cgi?id=1885415 --- Comment #5 from Robert Scheck <redhat-bugzilla@xxxxxxxxxxxx> --- (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 -- 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
