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...


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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

Reply via email to