Kevin Fenzi wrote:
> If the build has gone out in a rawhide compose, you need to just push
> out a fixed build. That could be something to fix it, or adding an Epoch
> and downgrading back to a previous version.
>
> If it's not yet gone out in a compose, you can file a releng ticket to
> have someone untag it, or you can tag the previous version into
> f31-updates-candidate and it will get pushed out instead. ie:
>
> koji tag-pkg f31-updates-candidate <the previous build that worked right>
>
> But you should only do that if it's not gone out in a compose.
> In this case it looks like that build has gone out. ;(
Can this policy finally get reconsidered? "dnf distro-sync" (and "yum
distro-sync" before it) has been available for years now. Is it really worth
introducing an Epoch that we will then be stuck with forever, also in
releases, just so that Rawhide users can upgrade with "dnf upgrade" rather
than "dnf distro-sync"?
I absolutely see the necessity of ensuring upgrade paths from release to
release, and even from release to Rawhide (because it ensures that the
upgrade path will work when Rawhide becomes a release), but from Rawhide to
Rawhide, just WHY?
Kevin Kofler
_______________________________________________
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
