On Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind wrote: > On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote: > > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > > It's bascially the same problem as Fedora has when users upgrade from Fredora > > > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path > > > between Fedoras is not maintained anymore and users need to do "dnf > > > distro-sync" to ignore the RPM versioning. > > > > > > All that stems from tha fact that a number of commits between parallelly > > > supported braches is not monotonic. > > > > > > > We did this long before rpmautospec existed. We switched to this > > behavior in Fedora 23 because we have never fully maintained "upgrade > > paths" across releases. > > > > Per private message with Neal this seems to be the Change that brought > it about: > > https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades > > I'm ... a bit surprised that we don't seem to have any documentation > stating explicitly that the assumption that NEVRAs in a newer release > are no longer assumed to be monotonically higher. That Change was primarily about replacing fedup with dnf-plugin-system-upgrade, changing from a custom-initrd-based solution that was rather fragile, to a special systemd target during early boot. dnf-plugin-system-upgrade uses 'distro-sync' because that's the most reliable and easy way to do the upgrade, suitable for end users. But this doesn't necessarilly mean that this is the only upgrade method that can be used. That Change certainly wasn't intended to change the packaging guidelines. In general, we still keep the upgrade path. It's not enforced all the time, but I think it's still good style. There is a lot of code out there that doesn't handle downgrades very well, in particular if there is data in files or state. So it seems always a bit iffy when a version is downgraded during a system upgrade. It seems that in practice, this actually happens mostly when people forget to build for rawhide or branched, not when they intentionally update a package in older releases only. > e.g. packaging guidelines still say "Rawhide is allowed to lag > *temporarily*" (emphasis mine) > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily > > I suppose the user facing documentation does say that upgrading using > only DNF is not tested -- but there's no guideline about loosening > monotonicity provided to packagers as far as I can tell. > > https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/#_can_i_upgrade_between_fedora_releases_using_only_dnf And I think that's all good ;) > - should we update the packaging docs? Does this need to be a new Change > Proposal or does this just need to go through the Fedora packaging > committee? (Those involved in the Change like zbyszek can probably > advise here) IMO, no. > - should we extend this further and say, if we no longer assume NEVRAs > are monotonically increasing in a new release, we should allow > packagers to use this opportunity to drop epochs in Rawhide? (likely > with proper announcement beforehand in devel@) IMO, no. The fact that you can upgrade between versions and mix packages from different releases, for testing or other purposes, is great. I wouldn't throw this out just to save the bit of hassle that is required to deal with Epochs. > (this might require coordination with RH's Leapp developers and > AlmaLinux's ELevate developers, to make sure those support upgrading > to lower NEVRAs too) It'd probably cause pain for our downstreams. While not a strict blocker, it's yet anothe reason to not do this. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
