Rawhide

Rawhide has the following Goals:

Rawhide is targeted at advanced users, testers, and package maintainers.

As a Rawhide consumer, you should:

If the above doesn’t match you, you may wish to instead follow the Branched release (depending on the point in the release cycle) or use regular stable Fedora releases.

See the wiki template for instructions on installing and using Rawhide.

There are a number of ways to communicate with other Rawhide users:

Package owners must build for Rawhide using Koji just like you would any other build; you do not go through the Bodhi process and the build becomes available almost immediately.

The Rawhide repository is composed every day starting at 05:15 UTC. All rawhide builds in the buildsystem at that time are included in the compose attempt. The compose process also attempts to build all the standard Fedora 'deliverables' (live and install images, ARM and Cloud disk images, container images and so on). If any release-blocking image fails to build as part of the compose, the compose is considered to have failed. If the compose completes successfully, the compose will be 'synced out' to the mirror system. (A system where the sync only happens if a set of automated tests run on it passes is planned, but not yet fully implemented).

Rawhide is under development/rawhide on the mirrors. You can find a local "development" mirror on the public mirror list. Compose time varies depending on number of changes, but is typically between 5 and 8 hours.

Composes are done in a rawhide chroot using the 'pungi' tool called from a script maintained by Fedora Release engineering. If the base set of packages in Rawhide needed to compose Rawhide are broken, the daily compose may fail.

A report for each Rawhide compose is sent to to the test and devel lists. This report contains output from the repodiff tool from the previous compose as well as a broken dependency report for packages with broken dependencies. Additionally, private email is sent to maintainers with packages containing broken dependencies.

Package maintainers should read and follow the Rawhide updates policy for building any packages in Rawhide.

If needed and approved by FESCo, mass rebuilds are done by Release Engineering in Rawhide a month or so before the next release branches from it. Typically these are done for a global change over all packages such as a new gcc release, or rpm package format.

Doesn’t rawhide eat babies / kill pets / burn down houses / break constantly?

No. Please stop telling everyone that.

So Rawhide is very stable and we can all use it?

No. See audience above. There are things that break from time to time, but if you are able to downgrade or troubleshoot, such issues aren’t too severe. Most users should still stick to stable Fedora releases, but Rawhide is a viable option for enthusiasts to experiment with.

I’m using a Stable Fedora release, but I want a newer package version that’s only available in Rawhide. Can I just dnf install it?

No Mixing releases like this is a bad idea. Better options are:

I want to run the Rawhide kernel on my stable Fedora machine. Can I do that?

Sometimes yes. The kernel is more self-contained than other Rawhide packages and you also can easily boot your older kernel if the Rawhide kernel goes wrong. Download and dnf install the package. However, note that Rawhide kernels often have debugging code enabled, which results in them performing noticeably worse than release kernels (they will be slower and consume more memory).

Is Rawhide a "rolling release"?

It depends on how you define that, but yes.

How can I tell when the Rawhide compose for the day has finished?

Check the reports sent to the test and devel lists, or watch fedora-messaging for the org.fedoraproject.prod.pungi.compose.status.change topic.

What happens during branching, does it affect my Rawhide release somehow?

No, you’re still on Rawhide and no action is required. (This was handled differently in the past).

How do I get out of Rawhide again? I want to switch to the Branched release or a stable release.

Note that downgrading your system to a lower release is not supported, not tested, not a good idea, and definitely at your own risk. The safest approach is to reinstall the system. If you really want to downgrade, at least make a filesystem snapshot first (if you use the default Btrfs filesystem).

One common use case is to switch your system to Branched right after it is created (split from Rawhide). In this case, the sooner you do it (after branching), the safer and easier it is—the difference between systems is minimal at that point. Downgrading after a long time, or downgrading to a stable release (which is completely different from Rawhide) will be more problematic.

You can (attempt to) downgrade to Branched or a stable release using DNF system upgrade (the same approach as for upgrades). However, because Rawhide uses a different set of system repositories, you need to explicitly disable those during the download phase, and explicitly enable the set or repositories used on non-Rawhide systems. So the download command would look like this (this will disable and enable the correct repositories, and if you have some additional (including third-party) repositories installed, it will keep them enabled or disabled as they are currently; replace NN with the target release number): sudo dnf system-upgrade download --releasever=NN --disablerepo='rawhide,rawhide-modular' --enablerepo='fedora,updates'

Everything else should be unchanged, you can use the rest of the aforelinked guide to proceed. There is a higher chance of encountering broken dependencies when downgrading, because while package dependencies must work correctly when going up in versions. They don’t need to work when going down. In that case, you can try --skip-broken or removing the offending packages (if possible), otherwise you’re mostly out of luck.

As a package maintainer do I have to build rawhide packages or does the nightly compose take care of that?

You must build for Rawhide yourself (using Koji). The nightly compose only collects packages already built and marked with the appropriate target (rawhide) in Koji.

Are rawhide packages signed?

All of them are now signed. Make sure you have gpgcheck=1 set in your repo file to take advantage of this.

Red Hat Linux "Raw Hide" announcement.

The name might come from the song with the same name that starts with "Rolling, rolling, rolling, …​".

At one time, Rawhide would freeze before release milestones. This was changed with the No Frozen Rawhide Proposal and Branched process which we now follow.