Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
>
>
> Vít
> _______________________________________________
> 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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux