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.