>>>> "MH" == Miro HronĨok
<mhroncok(a)redhat.com> 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<