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