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 <mhron...@redhat.com> 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. > > > Vít > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
