|upgrading from rawhide to final release
||[Nov. 3rd, 2007|11:56 am]
Every release cycle, there seems to be confusion about how to transition over from Rawhide (the nightly build of Fedora) to whatever the final release is (in this case, Fedora 8). This confusion is understandable, because at first glance the process is a bit magical. Let's see if I can explain it a little bit.
The short answer is this: you don't have to do anything! It will Just Work.
The first thing to understand is that on the day of a Fedora release, Rawhide and the actual Release are *exactly the same*. Rawhide, at this point, will have been frozen for about a week, and will not yet have opened up for contributions to the next release. And that is pretty much where we are right now. Rawhide *is* Fedora 8, and that will still hold true on the release day.
Everything else related to this question has to do with the fedora-release package on your machine.
The fedora-release package contains the release name, RPM gpg keys, some kickstart files, and most importantly, the yum repo files that tell your machine how to go about updating itself.
Let's take a look at what's on my laptop right now.
spevack@localhost ~ % rpm -q fedora-release
This package ships 4 yum repository files:
spevack@localhost ~ % rpm -ql fedora-release | grep yum
Let's take a quick look at what repositories are enabled, or disabled:
spevack@localhost /etc/yum.repos.d % grep enabled=1 *
This shows us that there is a repository enabled in the fedora.repo file and in the fedora-updates.repo file. If I look in those files, in both cases that is the Fedora 8 repository that will live at /pub/fedora/linux/releases/8/ in our mirror directory structure.
But if you have been using Rawhide since Fedora 8 Test 1 or something like that, you have been used to having the fedora-developent.repo file be enabled, and the main fedora and fedora-updates files disabled (because otherwise you'd be getting the Fedora 7 packages, and not the Fedora 8 development ones).
As the Fedora 8 Release Candidates have come out in the past few days, Jesse made the change to fedora-release to have it point to the /releases/8/ directory instead of /development/ because that is how it has to look for the final release of Fedora 8.
That /releases/8/ directory isn't active yet, because Fedora 8 hasn't been released yet. But our mirrors currently have a redirect that points over to Rawhide. On Thursday, it is a trivial operation for Jesse to take that redirect away. Then the Fedora 8 directory is active -- people can install, we can push updates, etc. Separately, Rawhide can then be opened back up for Fedora 9 development, and a new fedora-release package that configures yum to look back at Rawhide will be placed in it. People who want Rawhide can install that package or tweak their yum repository files and be off and running.
What's the point of all of this?
It makes the upgrade path as hands-off as possible. Chances are that if you installed a Test release of Fedora or a Release Candidate, you want the final version of the release when it is available -- you don't want to stick on Rawhide.
By altering the default settings in fedora-release at the right time, and also by using redirects, the Release Engineering team can achieve this affect without requiring the user to change anything.
So if you have installed one of the Test versions of Fedora, you are already all set up the way you need to be. Your machine will "become" Fedora 8 at the right time.
The folks who want to *always* run Rawhide are the ones that occasionally have to tweak something manually, but that's ok with us.
IIRC, I argued for this exactly this methodology in fedora-maintainers list a couple of releases back and got irrational push back just like the current one against KDM being the default DM for KDE in Fedora DVD image. Thankfully sometimes, people do come around and change their thinking on such things. Other times you get accused for all sort of things ;-)
The magic that redirects fedora-8 -> rawhide right now isn't actually a symlink on the mirrors, but is a redirect file that's part of MirrorManager. Same effect though, without the churn on the mirrors. Next Thursday we'll simply remove the redirects on the mirrorlist servers, and fedora-8 will point at the new repositories, and rawhide will continue to be rawhide.
2007-11-03 05:41 pm (UTC)
Re: mirrorlist magic, not a symlink
i fixed my terminology. thanks matt
2007-11-03 06:10 pm (UTC)
$ yum repolist
repo id repo name status
fedora Fedora 8 - i386 enabled
updates Fedora 8 - i386 - Updates enabled
> The folks who want to *always* run Rawhide are the ones that occasionally have to tweak something manually
They'll also be in for a lot of "fun" as there's the breakage warning from the maintainers of X.Org X11 in Fedora, and for KDE users also the KDE-4-related breakage warning from KDE SIG, and that's just the planned ones. ;-)
So if you want to help testing without breaking your X11, F8 updates-testing might be the better place to be on. There are always too few updates-testing testers anyway, and there's several 0-day testing updates being prepared which could use some testing to get into the stable updates as quickly as possible.
Nice overview, thanks!
But how about those of us who have fedora-development.repo enabled. How are we moved to F8? It seems to be stated indirectly that it happens automatically.
It is my understanding that:
fedora.repo has gpgcheck=1
development packages are not signed
fedora.repo thus really can't be used as is before release - early adopters must disable gpgcheck and remember to switch it back (not that it matters; they have been installing unsigned packages and should thus assume that their system is infected and reinstall.)
fedora-development.repo has gpgcheck=0 but is disabled by default - early adopters can thus alternative enable this.
So no matter what, the .repo will be modified and not be overwritten by updates, so testers will have to move back by hand. Or???
It seems like a better scheme would be to make fedora-9.repo very early in rawhide. Initially it could point at rawhide, later on to the F9 betas, and automatically move on to the released F9.
fedora-development.repo has gpgcheck=0 but fedora.repo and fedora-updates.repo have gpgcheck=1
So when the folks who have been on fedora-development.repo start getting updates on Thursday (which they will automatically), signed packages will gradually replace unsigned ones. For example, Firefox 18.104.22.168 is going to probably be a zero-day update, and it will come in signed, replacing the unsigned Firefox 22.214.171.124 that was in the development RPM.
But the folks who have been on fedora-development.repo will also remain so, and thus start getting F9 packages when they appear, right?
2007-11-06 09:24 am (UTC)
Still yum-cache missing
Except that it doesn't work for those who want to save bandwidth and use squid to make shared cache. So, I have in /etc/yum.repos/ couple of *.rpmnew files, which I forgot to edit. Oh well. Why, oh why, this enterprise friendly distribution still doesn't have yum-cache. Oh well.
2007-11-06 09:40 am (UTC)
Re: Still yum-cache missing
2007-11-06 08:30 pm (UTC)
Fedora 8 updates
The Fedora updates directory for F8 already has updates in it - I assume these are the start of the zero-day updates. When F8 gets released, ex Rawhide systems will apply these updates. Will these updates be immediately released into Rawhide, or will F8 become more up-to-date than Rawhide?
2008-04-20 07:11 pm (UTC)
I think it is a great idea to have rawhide users automatically moved to the stable release. That makes a lot of sense to me. Kudos to the people that made this happen. I appreciate your work.