Wandering Thoughts archives


What it would take for me to use Fedora Rawhide

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.)

linux/WhyNotRawhide written at 22:59:53; Add Comment

The potential problems with distribution downgrades

One of the things I wish for every so often is the ability to downgrade Linux distributions, not just upgrade them (which is common and generally well supported; I can think of only one large Linux distribution without upgrade support, and you can argue that Red Hat Enterprise Linux is a special case). This wouldn't be as good as various forms of 'live upgrade', but it would still be useful and it would certainly make me a lot less nervous about doing upgrades.

Conceptually, a downgrade is easy; you run the normal package upgrade selection process in reverse, replacing all of the current packages with the most recent versions from what you're downgrading to. In theory this should be relatively simple to implement.

(I think you'd want to do it from a standalone environment, because otherwise the ordering constraints might get what programmers call 'interesting'.)

In practice I think that the big problem is the issue of reverting various sorts of configuration and data files to older versions of their formats. For example, consider a syndication feed reader where the format for storing your feed information changed between major versions. When you upgrade your distribution and get the new major version of the feed reader, it will migrate your old feed data to the new format and then carry on as normal. But when you downgrade you need to run this in reverse, converting new format files to old format files that the older version of the feed reader can read. And there are generally no tools for this.

The result is that while a downgrade is technically possible, the result might not be very useful without a lot of fixup work, and thus without a lot of work writing ad-hoc fixup tools (assuming it's even possible without losing significant amounts of information, which it may not always be). Thus I don't think it's any surprise that no Linux distribution has attempted to support downgrades, however nice they would be to have; what you could give people for a reasonable amount of work would be so fenced in with caveats and cautions that it would be useless to most users.

linux/DowngradeDifficulty written at 04:19:34; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.