On Mon, Mar 11, 2019 at 6:48 AM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Mon, 11 Mar 2019 at 05:29, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > > > > Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a): > > > 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... > > > > > > > > > > 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. > > > > Whatever changes to EPOCH rules will need additional logic added to > all the various buildsystem logic where a human can't sit around and > choose 'oh yeah I want to go to that older epoch' because the build is > automated somewhere. This has been the major reason why various 'EPOCH > should go back' or 'I want an EPOCH to my EPOCH' conversations in the > past have floundered (I think we last looked at this in 2009 and I > know we did in 1999.. so maybe this is a 10 year cycle?). There is a > LOT of stuff written on the assumption that EPOCH's go forward and > never backwards. Changing the rules here have effects in many many > other build systems and install tools which sites are using and that > usually ends up being too big of a problem to solve. [Yes we can fix > our koji/bodhi/greenwave/waiverdb/pungi/mock/copr, and their koji and > maybe that other other koji... but how do we fix the plague server > building stuff at large industrial complex-1 or the clone of the OSBS > at large-government-research-place-2. ] > > [If I remember the discussion from 2009 correctly, it was a similar > problem and the idea was to have an vip epoch which sat in front of > epoch and could override it so you go back to epoch.. this led to a > bunch of elephants standing on each other. The 1999 one was having > release logic in the installer which could over-ride epochs.] > I don't remember how Plague handles this anymore (forgive me, but I haven't interacted with Plague since 2005!), but both Koji and OBS don't care if the Epoch goes up or down. Koji uses NVR as a key (without Epoch), and OBS freely allows EVRs to go up and down. Any change requires a release bump anyway, so from that perspective, things are usually fine. So I think from that perspective, we should be okay. -- 真実はいつも一つ！/ 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
