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), then I can imagine that reset of epoch could work. Otherwise I am against resetting epochs. Vít _______________________________________________ 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
