What it would take for me to use Fedora Rawhide

February 28, 2009

Sparked by Pete Zaitcev, here's a thought: why don't I use Fedora Rawhide? That's a serious question, since I'm sort of in the natural target audience; I've got the skills and the general interest and willingness, and I run and have run relatively bleeding edge versions of various things (at one point including kernels, although I've gotten lazy since then).

In thinking about it, what it comes down is that while I can stand irritations, I can't stand show-stoppers. I don't have spare machines, so I need both my office and my home computer to work reasonably well all the time; I can't afford to lose a day or three because, say, the web browser has stopped working or the X server gets unusably slow after running for a couple of hours.

(Here I am discounting the possibility of true catastrophes such as a broken libc package or the like, partly because I understand that they basically don't happen these days.)

Now, I don't demand that all of the other bleeding edge things that I use now never break. Instead I deal with any breakage by immediately reverting to the previous and working version, waiting a bit, and trying the current version again. Sometimes I have to wait a while before the new version works, but that's all right; I'm not losing productivity except when I feel like it.

The equivalent for Rawhide would be package downgrades, so that if a Rawhide update broke things, I could and would revert back to the last working set of packages. Unfortunately, as far as I know Rawide has no general support for this (probably partly because it's difficult in general), and I believe that Rawhide removes old versions of packages from the repositories in order to save disk space, just like Fedora updates.

You could construct something like this by hand by keeping a copy of all RPMs that yum downloads and installs, along with either yum's records of installs and upgrades or just a list of what package versions were on the system at various points in time. My impression is that yum is a bit too willing to remove RPM files for me to trust it to keep the copies; possibly the solution there is some sort of proxy that's configured to always keep copies (a plain squid instance or the like might work).

(I'm prepared to run the risk of having to do a certain amount of surgery if there are problems such as bad RPM postinstall scripts, and also the general risk of config file format changes and so on.)


Comments on this page:

From 83.145.208.36 at 2009-03-02 12:48:03:

Knowing the areas you like to dig into, the truly satisfactory solution would perhaps be closer than you think...

... snapshots? Z? F?

- j.

By cks at 2009-03-03 00:20:32:

I don't think that snapshots and rollbacks are the right solution, because I dislike the side effects they have. The whole explanation is long enough that I put it in its own entry, RollbackVsDowngrade.

Written on 28 February 2009.
« The potential problems with distribution downgrades
Some gotchas with ZFS in Solaris 10 update 6 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 28 22:59:53 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.