Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a): > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch <vondr...@redhat.com> 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 <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. >>> > I'm confused, why would that matter? And DNF always reports NEVRA... > >
The epoch are used in cases like: 1. There is foo version 1.0 2. foo is updated to version 2.0, because it seems it is safe. 3. It is discovered, that it breaks stuff, so the decision is go back to 1.0 and add epoch. 4. Eventually, we really want to have 2.0 in the release or even something newer. Now, the epoch could be removed, but it is not possible, because it has the highest priority. In this case, if DNF said something like "you have installed foo-1:1.0, but there is available foo-0:2.0" it would give me hint. From the start it would be annoying, but once we would reach the point 4, I would, at least, know that I should do distrosync or something. V. _______________________________________________ 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
