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.] -- Stephen J Smoogen. _______________________________________________ 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
