Hey all, So as you all know, Pagure 5.0 was released[1]. With 5.0, I've taken over primary maintenance of the package outside of epel7-infra, which means that Fedora and EPEL7 packages are generally maintained by me (with packaging changes generally synced from upstream), since Pierre-Yves doesn't have time to maintain it. We've already received the approval to re-sync pagure's EPEL7 package with Fedora to update to 5.0[2]. However, this presents a bit of a problem. Pierre-Yves updates the pagure package for epel7-infra before making the general release that I can consume and push to Fedora and EPEL7. This wouldn't be an issue, except that the DistTag for epel7-infra is the same as epel7 (.el7). This means I'm locked out of that NEVR for EPEL7 updates, due to the nature of Koji considering NEVR of builds globally unique. This is frustrating because it means that I can't maintain the common spec file for both Fedora and EPEL7 (which is in turn primarily maintained upstream in the pagure git repo). Of course, I can just bump the Release to be above the epel7-infra build, but that means I'm playing NEVR games, and I don't want to do that. And if there needs to be distinct changes for epel7-infra, this is going to be an unpleasant fight. I'd like to propose that we change epel7-infra so that the DistTag defined in %dist is ".el7.infra" instead of ".el7". This will prevent the conflict and have the advantage that the infra tag is higher by default. For this current update round, I'm going to be putting a higher Release value because I need to anyway, as there's a bug in the way pagure is done that breaks packaging in Fedora and openSUSE[3]. But in the future, I'd like to have the freedom to use the correct NEVR everywhere. What do you all think? [1]: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/message/ER3ZEST24R7ZC4UV3PJVWBAHQJDE3CLN/ [2]: https://meetbot.fedoraproject.org/teams/epel/epel.2018-09-26-17.01.html [3]: https://pagure.io/pagure/issue/3706 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
