Dne 30.11.2017 v 10:35 nicolas.mailhot(a)laposte.net napsal(a):
I totally agree with the spirit, but that would require Red Hat taking a more active role
in backporting package tooling to RHEL/EPEL.
Latest guidelines are always more efficient for everyone (Red Hat employees includes),
but all too often they can't be applied to EPEL because no one at Red Hat pushed the
corresponding rpm, mock, rpmdevtools, macro updates to RHEL or EPEL :(
The more packages Fedora ships the more inefficient it is to require RHEL/EPEL packagers
to use old guidelines in every spec files to avoid tooling backports.
I think things are changing in Fedora as well as in Red Hat.
Fedora is more agile especially in regard of RPM development, but on the
other hand Red Hat will be always lacking behind due to RPM being
crucial piece of RHEL. On the other hand RHEL is more agile then it used
to be especially due to RHSCL. But also in other aspects, such as
rebases of key packages such as OpenSSL or even Kernel.
OTOH, speaking as a Ruby maintainer in Red Hat, the agility does not
make the situation with guidelines easier, since we cannot anymore say:
"Ah, EPEL7 was based on F19, so apply F19 guidelines". This is simply
because Ruby in RHEL 7.4 newly supports the same set of macros as Fedora
Rawhide, but does not support the provide/require generators due to RHEL
7 RPM limitations. And frankly, should I go to FPC asking for approving
(backward compatible) guideline changes due to change in RHEL? That does
not make any sense.
However, one day, if/when next RHEL comes, I want to see RHEL using the
latest and greatest technologies available in Fedora. I hope I can
generalize this into everybody in Red Hat. And this is another reason
why the guidelines should cover only Rawhide and should promote the most
recent technologies. If we are not going to use/promote the latest
advancements, there would be actually no reason for next RHEL at all. We
could just stay in distribution stone age forever.