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.
>
>
> Vít
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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