>>>>> "MH" == Miro Hrončok <mhroncok@xxxxxxxxxx> writes: MH> One thing to consider here is other packages that have Requires MH> etc. on something like "foo > 1:1.2", so if it is automated, this MH> part needs to be automated as well. Indeed. And of course this breaks any such dependency outside of Fedora as well. (Either in COPR repositories, RPMFusion, or local packages.) I should have mentioned this as a potential downside, since it was part of previous discussions. MH> If we do this, we might have a "flag day" but not automated for all MH> 756 packages, but opt in. Sure, maybe at first. Stage it in over a couple of releases if necessary, or having a couple of flag days. Though it's not quite as many if you exclude the Epoch: 0 ones. (Though I recall that there is some subtlety between Epoch: 0 and no epoch at all.) But that's an implementation detail; the fundamental question is whether there is any general support for dropping epochs, and more specifically if FESCo would accept it on principle. And I can understand why they may not, because while epochs are annoying, we've certainly been living with them for quite some time. MH> Aka we create a window on rawhide, and packagers would sign up for MH> this, we announce the window, let them do it, and we close the MH> window... ? The issue is that if a compose happens while the window is open, we have more than one rawhide update where distro-sync is needed. I think it's worth spending a bit of effort to minimize the issues for those running rawhide. MH> However I'm not sure it's worth the effort. Yes, that's basically the problem. History has shown that we can live with epochs. But even if it's a limited effort, it would be nice to give packagers who want to get rid of epochs a way to do so. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
