I've had this on my personal task list for a while now, but it turns out to be rather subtler than I thought, at least for Rawhide.

We can do it quite straightforwardly for Branched, but we can't really do it yet (except blind) as we don't have a Branched right now.

The problem for Rawhide is that Rawhide doesn't really work like other releases. The fact that our console upgrade test works for Rawhide is actually kind of odd, and relies on a messy hack someone put in place at some point.

So here's the skinny. There are various Fedora repo definitions. The 'stock' ones are in fedora-repos. There are special Rawhide repo definitions in the package fedora-repos-rawhide.

According to Dennis Gilmore, the 'official' way to use Rawhide is to install fedora-repos-rawhide and then enable the repository rawhide and disable the repos fedora, updates and updates-testing. To upgrade to Rawhide, you're supposed to do that, and then run dnf system-upgrade download --releasever=26 --nogpgcheck (at present - you have to know the 'right' release number for Rawhide and use it).

We don't do anything like that. Instead we just leave the repo definitions as they are (we don't install fedora-repos-rawhide at all) and do dnf system-upgrade download --releasever=rawhide --nogpgcheck.

...and this works. Which Dennis was quite surprised about, so I went and looked into why. Here's why!

When you pass --releasever to dnf you're basically telling it 'just go ahead and use whatever repos are configured (or otherwise specified on the command line), but when you see $releasever, don't replace it with whatever you detected the current installed system's release version is. Replace it with this value instead'. So when we install Fedora - say Fedora 25 - and use the default repos from fedora-repos and pass --releasever=rawhide, we're telling dnf to use the repos fedora and updates - since those are the ones that are enabled by default - but to replace $releasever in their values with rawhide, not 25.

OK, so what do the repos actually say? Well, the interesting bits of fedora look like this:

[fedora]
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

the interesting bits of updates look like this:

[updates]
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

so basically we're going to wind up hitting these URLs, on x86_64:

• https://mirrors.fedoraproject.org/metalink?repo=fedora-rawhide&arch=x86_64
• https://mirrors.fedoraproject.org/metalink?repo=updates-released-frawhide&arch=x86_64

the first of those is fine, it's what the rawhide repo definition from fedora-repos-rawhide says anyway, if you use that repo. The second one, however, is kinda crazy, and it's what Dennis was expecting to trip us up, because Rawhide has no updates repository. However, at some point, someone has put some kinda hack in place: if you hit that URL, you'll see that it works, and it's actually set up to work exactly like the fedora-rawhide target. This is also the case for the updates-testing-frawhide target. Basically, someone at some point told MirrorManager to treat updates-testing-frawhide and updates-released-frawhide just the same as fedora-rawhide, which makes using dnf --releasever=rawhide with the default repos 'work' (though it's a bit of a hack as you wind up using two or three identical copies of the same repo, depending on whether you have u-t enabled).

Why does all this matter? Well, because now we more or less know how dnf behaves if you just tell it "I want to upgrade to 'rawhide'", but I don't know what GNOME Software will do. I've poked into a bit and so far made it as far as pk_task_upgrade_system_async in PackageKit. Right now GNOME Software won't even offer an upgrade to Rawhide, ever; that's fairly trivial to fix, and I might patch it tomorrow and play around just to see what happens next. But I wanted to jot all this down somewhere so we have the notes available while we look at what G-S / PK actually do if you say 'upgrade me to Rawhide, please'. We should probably test both what happens if you leave the 'default' Fedora repos in place, and what happens if you disable fedora and updates and enable rawhide.

Right now, Dennis still maintains that just using the default repos and dnf --releasever=rawhide is wrong and we shouldn't do that, we should switch the repo definitions before running a Rawhide upgrade. I'm kinda of the opinion that it'd be nice to just bless the --releasever=rawhide approach, coming up with a slightly more elegant hack for what MirrorManager does for the updates and updates-testing repos in that case, because it'd prevent us having to have a variant repo definition for rawhide and tell people to manually change the repo configuration when they want to use Rawhide (and having the fedora and updates repos disabled by default in the Rawhide fedora-repos package, and remembering to keep flipping that back to enabled when we branch). But I could be convinced otherwise, I want to kick it around with Dennis. If we do decide the separate rawhide repo config is the one and only true way to do it, we should adjust the console tests to do the repository reconfiguration when upgrading to Rawhide.