On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > > Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > >>>>>>> "MH" == Miro Hrončok <mhroncok@xxxxxxxxxx> writes: > >> MH> On 08. 03. 19 21:16, Neal Gompa wrote: > >>>> I really wish we'd allow Epochs to be reset on distribution upgrades. > >>>> With dnf distro-sync (which is used by system-upgrade) Epochs don't > >>>> really matter and upgrades work as intended anyway... > >> MH> Let's do a Fedora change? Coordinate with FPC? > >> > >> We (FPC) have talked about this before but I don't think it's really up > >> to FPC. The change process isn't really the right way to do it, either, > >> since this is really a policy revision. I just think FESCo needs to > >> decide whether or not it would like to relax the policy, and if so, how. > >> > >> Here are the relevant points as I see them (unless I'm forgetting > >> something): > >> > >> * dnf system-upgrade generally handles versions going backward without > >> issue. The specific case of epoch being reset is not an issue. > >> > >> * dnf upgrade would not handle this, causing problems for those running > >> rawhide or using unsupported methods of upgrading between releases. > >> > >> * Those running rawhide would have to run distro-sync in order to > >> upgrade (which would of course reset any locally built updated > >> packages and such). They would have to do this every time any > >> installed package drops epoch. > >> > >> * Those using an unsupported method of upgrading would need to > >> incorporate distro-sync. > >> > >> * Dropping epoch outside of rawhide would generally be bad. > >> > >> * Koji and the compose process do handle things "going backwards", as > >> this has happened multiple times in the past without things dying. > >> What's important there is which version was most recently tagged. > >> > >> * Bodhi shouldn't be involved here as this would be restricted to > >> rawhide. > >> > >> Personally I'm in support of relaxing the restriction in some form, but > >> I prefer a single "drop Epoch: day" where epochs in rawhide are > >> _automatically_ removed and the packages rebuilt. This gives a single > >> point in time where rawhide users need to do a distro-sync in order to > >> properly track updates. Allowing epochs to be dropped without > >> coordination seems to me to be a burden on rawhide users, but I don't > >> think a single flag day would be problematic. > >> > >> I would expect the first flag day to be busy. I see 756 Epoch: tags > >> currently, though 161 are set to 0 for whatever reason. Afterwards I > >> would expect no more than a small number of packages per cycle to > >> acquire Epoch: tags. > >> > >> - J< > > > > If DNF were helpful and was able to report packages, which has higher > > NVR then E(NVR), > > > I meant (E)NVR actually. > > > V. > > > > then I can imagine that reset of epoch could work. > > Otherwise I am against resetting epochs. > > I'm confused, why would that matter? And DNF always reports NEVRA... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
