On Mon, Mar 11, 2019 at 6:48 AM Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Mon, 11 Mar 2019 at 05:29, Vít Ondruch <vondruch(a)redhat.com> 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(a)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
<mhroncok(a)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.
>
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!