On 8/4/19 5:17 AM, Kevin Kofler wrote: > 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"? You're welcome to ask fesco to reconsider it. That said, distro-sync is not ideal a lot of times. If you install locally created packages to test something or fix a bug until a official build is out, the distro-sync will move them all back to the ones in the repos. I've also run into cases where distro-sync failed to update at all due to broken deps, where update did work. > 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? This was discussed in the last big thread on that, and the big thing (at least to my mind) was that we don't want rawhide to be 'shifting sands'. Right now if something lands you can be reasonably sure it will get fixed for issues and that you can count on it being there for rebuilding against. Sure, someone could do an Epoch and downgrade, but the resistance to doing that is actually an advantage here. We don't want people seeing a new build of something they depend on, rebuilding their entire stack on it, only to have the package downgraded and causing them tons of work. I think downgrading should be a decision not made lightly. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
