On 08. 03. 19 23:19, Jason L Tibbitts III wrote:
"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.
One thing to consider here is other packages that have Requires etc. on
something like "foo > 1:1.2", so if it is automated, this part needs to be
automated as well.
If we do this, we might have a "flag day" but not automated for all 756
packages, but opt in. Aka we create a window on rawhide, and packagers would
sign up for this, we announce the window, let them do it, and we close the
window... ?
This needs a lot of consideration for sure, but I think it can be done somehow.
However I'm not sure it's worth the effort.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
