Dne 30.11.2017 v 10:35 nicolas.mailhot@xxxxxxxxxxx napsal(a): > Hi, > > 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. > > Regards, > 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. Vít [1] https://pagure.io/packaging-committee/issue/710 _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
