On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > > with using Epoch's much more commonly. > > That is due to the "Rawhide can never go backwards" policy, which I still do > not understand the point of, especially in the light of "distro-sync" having > been supported by both the old yum and the new dnf for years. > > We allow even updates-testing to go backwards, so why not Rawhide? I think > the only place we should ever enforce upgrade paths in is stable releases. > Rawhide can go backwards just fine. The fix is simply to use dnf distro-sync > instead of dnf update. (Enforcing the upgrade path from stable releases to > Rawhide may make sense to prepare for when Rawhide will eventually be > branched into a release, but what is the point of enforcing the upgrade path > from Rawhide at day d to Rawhide at day d+1? Rawhide users can just be > taught to use distro-sync, and users of stable releases will never see this > upgrade path "breakage".) > > Red Hat Linux and early Fedora had worked fine for years without that > policy, and Epoch was required less often back then. > > So please let us just repeal that "Rawhide can never go backwards" policy. This is actually a fair point, but I wonder what prevents us from doing it today. The only thing I can think of is that we have no mechanism to choose what goes in rawhide and what does not, from the moment you build it, it will go into rawhide. So maybe gating rawhide, would give us that mechanism to a) prevent package we know are broken from entering rawhide, b) potentially remove from rawhide package we later find are breaking things. I guess another issue with removing something from rawhide is that something else may have been built on the top of it, thus removing A would imply, automatically rebuilding B, and C, and D... So while gating rawhide would prevent this, acting on it once it landed in rawhide will be a little trickier. Am I missing something? Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
