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